Adds `BlackboxingActor` boilerplate and implements `getBlackboxingActor`
Testing: Added a geckordp test for `getBlackboxingActor`
Fixes: Part of https://github.com/servo/servo/issues/36027
Signed-off-by: Freya Arbjerg <git@arbjerg.dev>
cargo-about is only used in the ./mach release command, which will only
be used by very few people (when preparing a release). Hence it doesn't
make sense to install it for everyone, and instead we can just tell the
user how to install if it is missing, and save resources for everyone
else.
Testing: Not tested, but trivial
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
Based on our linux-wpt.yml workflow update our bootstrap and
devcontainer package list.
This should make the local environment closer to our CI environment when
running WPT. We only purge the droid font in the devcontainer, since we
shouldn't purge packages for the user.
mesa-vulkan-drivers was added in
71e0372ac1, so it's probably required for
WebGPU.
fonts-noto-cjk was added in 2b0d2ecc73.
In both cases no reason was given why it can't be in bootstrap, so
presumably its just an oversight.
Testing: bootstrap is ran in CI, and the packages were already being
installed by the wpt workflow.
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
This PR removes support for passing direct test file paths (e.g.,
`./mach test-unit <test_file.rs>`) to `mach test-unit`.
Previously, this shorthand was supported in `test-unit` but was
subsequently broken in #39897. Supporting this behavior now requires
extracting test names from a generic parameter list, which is
error-prone due to the presence of arbitrary arguments and inconsistent
argument ordering.
With this change, `mach test-unit` aligns more closely with standard
Cargo test patterns. Users are expected to specify test modules or
patterns instead (e.g., `./mach test-unit <module>::` or using
Cargo-compatible arguments).
This simplifies the implementation and avoids maintaining fragile logic
for shorthand support that was not widely used.
---
### Testing
* Ran `./mach test-unit` with various valid patterns and module-based
inputs
* Verified that tests execute correctly across supported use cases
* Confirmed that removal of direct file path support does not affect
standard workflows
---
Fixes: #41065
---------
Signed-off-by: Emmanuel Paul Elom <elomemmanuel007@gmail.com>
Check if rustup is available before calling it.
If it is not found, skip the step with a warning instead of crashing.
This allows users who installed Rust through their distribution's
package manager (without rustup) to build Servo without errors.
Three places were updated:
- In command_base.py I added a skip automatic target installation for
cross-compilation
- In base.py, I added the skip toolchain installation
- In, bootstrap_commands.py , it is a skip clean-nightlies if rustup not
found
Fixes: #43871
Signed-off-by: Messi002 <rostandmessi2@gmail.com>
TL;DR: We increase stack size of `ScriptThread` to 8MiB, and set Stylo
stack size environment var
to 8 MiB for all builds. This only reserves virtual memory space which
is
basically unlimited for 64-bit machine,
matches the recursion depth of Chromium for the example, which also uses
8MiB.
Stylo stack increase is necessary to prevent overflow when
refreshing/navigating to the example,
probably because initial load restyle incrementally but not refresh.
Testing: Added a Servo-specific test.
---
For example in #43845, we get stack overflow when we got more than 394
nested shadow roots.
For Chromium, it happens for more than 1631:
<img width="290" height="127" alt="image"
src="https://github.com/user-attachments/assets/b3d75627-4e80-4586-9b85-4b58d8a0cd33"
/>
For Firefox, it overflows for more than 1052.
Initially I thought we didn't implement this optimally, and have
unnecessary recursion depth.
But the real reason is explained in Rust std:
> The default stack size is platform-dependent and subject to change.
Currently, it is 2 MiB on all Tier-1 platforms.
For Chromium, the visual studio dumpbin shows the stack size :
```
Dump of file C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
OPTIONAL HEADER VALUES
800000 size of stack reserve
```
This is hex value, which is $8*16^5$, exactly 8MiB.
After we make the same change in Servo, we are fine at 1601 and
overflows at 1602.
This matches Chromium behaviour, defeating firefox, and should not
create much overhead,
as this only reserves virtual memory space:
I tried to increase the value to 512MiB, but task manager still says
73MB RAM used,
and we won't crash even with 10000 nested shadow roots.
But that is just for more evidence and uncalled for.
Fixes: #43845
---------
Signed-off-by: Euclid Ye <yezhizhenjiakang@gmail.com>
This commit removes some unneeded lines from README.md in the
linux_packages folder. This will trigger `book-export` to run, since it
creates a diff in that folder.
Since the export only happens if there is a diff, and there have been
not changes since the auto sync PR landed, the formatting related
changes never got upstreamed (sorting the packages).
This also duplicates as a test of the #43920 (merged), to be absolutely
sure that it works as intended.
Testing: not required / in a way this is a test of our book-export
action.
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
Previously the mode is always "". Now we set it to the real profile.
Note that previously, all the build has 2MiB stylo thread stack size,
which is unintended.
What we wanted is to make it so for debug build, and 8MiB for ASAN.
Now, those other than debug/ASAN would have 512KiB default stack size
again.
Testing: Manually tested and printed the mode at
0b6b97384d/python/servo/command_base.py (L419-L420).
Fixes: #43927
Signed-off-by: Euclid Ye <yezhizhenjiakang@gmail.com>
This name was mistyped during the rename of the servo crates to be
`servo-` prefixed.
Testing: Manual testing with `./mach build --with-asan`. This is not run
in CI.
Signed-off-by: Jonathan Schwender <55576758+jschwe@users.noreply.github.com>
This PR considers the following constraints:
- Resources must be available when building servo via a published
crates.io package (i.e. no `../../../resources/<file>` file references).
- Minimal setup when writing tests (`nextest` spawns each test in its
own process, so we don't want to explicitly initialize the resource
handler for every `#[test]` fn)
- Use local resources when developing locally
- Support loading the resources from a proper resource directory if the
embedder wishes so, including via a custom mechanism, not necessarily as
files
(File) Resources that are only accessed from servoshell are out of scope
of this PR, since it mainly focusses on unblocking publishing `libservo`
to crates.io.
Baking the resources into the binary by default simplifies the setup a
lot. We already supported that before, but only for testing purposes and
explicitly not for production builds.
Using [`inventory`](https://crates.io/crates/inventory) adds a simple
way for the embedder to replace the default baked in resources, while
also keeping the test usage of baked in resources simple.
rippy.png is also referenced from image_cache - We simply duplicate it,
since the image is small, to avoid adding unnecessarily complex
solutions like adding a dedicated crate.
Testing: Covered by existing tests. [mach try
full](https://github.com/jschwe/servo/actions/runs/23811669469)
Fixes: Part of #43145
---------
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
Add the minimum amount of FreeBSD-specific code to Servo, where no
platform-neutral fallback exists.
Testing: I've succesfully built and run Servo on FreeBSD with these
changes (and some fixes to dependencies). There's no functional change
to any other targets. This pull request was created with Servo running
on FreeBSD.
Fixes: #11625
---------
Signed-off-by: Juhani Krekelä <juhani@krekelä.fi>
Co-authored-by: Juhani Krekelä <juhani@krekelä.fi>
This prevents unintended updates the `uv.lock` file which must be
reverted locally.
Testing: As this just fixes a runtime issue when running `test-tidy`,
this
probably doesn't deserve a test.
Signed-off-by: Martin Robinson <mrobinson@abandonedwig.info>
Co-authored-by: Martin Robinson <mrobinson@abandonedwig.info>
Add further missing repository keys / descriptions, which I missed in
#43451 due to a suboptimal grep (assuming that rust-version.workspace is
always the last item).
Additionally fix crate self-references, which caused cargo-publish to
fail, due to it trying to fetch the crate from crates.io.
When specifying the current crate in `[dev-dependencies]` to enable a
test feature or similar, apparently one should not use `workspace =
true` and instead use `path`.
This requires extending the previously added `tidy` check, to allow
`path` dependencies in this specific case outside of the workspace
Cargo.toml.
Testing: Covered by existing tests
---------
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
In preparation for a release to crates.io, bump the workspace version to
match the current servoshell version, and let the servoshell version use
the workspace version again. This makes versioning for us easier, and
makes more sense since servoshell is considered to be just a demo for
servo.
The `./mach release` command is updated to support bumping the workspace
version, and patch the version requirement of all workspace-versioned
workspace dependencies.
Testing: Can be manually verified by running `./mach release
<new_version>`. Note that this just bumps the version numbers, and
doesn't release anything, so it's perfectly safe to run.
---------
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
In order to prepare for publishing this PR does the following steps (see
commits):
- Move all `path` dependencies to the workspace Cargo.toml, and
reference that.
- Move all path dependencies in the workspace Cargo.toml into a
dedicated section, to make bumping version numbers easier later.
- Add the version requirement. Note that we currently only version bump
servoshell. There was agreement to version everything with the same
version as servoshell, but that be done in a follow-up. The diff is
already large enough as is.
- Add a tidy lint to catch `path` usages outside the root Cargo.toml. I
switched to [`tomllib`] (which was added to the python stdlib in 3.11),
since the third-party `toml` library failed to parse Cargo.toml files
with `workspace.version` (did not like the `.` in a `key`).
[`tomllib`]: https://docs.python.org/3/library/tomllib.html
Testing: Should be covered by regular CI testing.
---------
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
The `InspectorActor` and its children now query the
`BrowsingContextActor` for the active pipeline ID and script sender
instead of storing their own copies, which become outdated on
navigation. Previously, the inspector remained permanently stuck to the
pipeline that was active upon launch. Now, connecting a fresh devtools
client session after navigation allows inspection of each
`BrowsingContext`'s active DOM.
Navigation within a continuous remote debugging session still breaks the
Firefox inspector panel. This is due to multiple compatibility issues
with the protocol implementation, which will be addressed in separate
PRs.
This PR does not touch `TimelineActor` or `FramerateActor`. These are
theoretically affected by the same issue as the `InspectorActor`, but in
practice neither is ever instantiated. It seems both have been
effectively unreachable code since 1aab10f2 and will require more
extensive work and testing that is beyond the scope of this change.
Testing: Updates to the `WalkerActor` and `BrowsingContextActor` are
unit tested via the new `test_walker_observes_new_dom_after_nav` case in
`devtools_tests.py`. There are no existing unit tests to reference for
the highlighter and style actors; these have been tested manually but
this PR does not introduce further automated tests. This PR also
improves handling of `tabNavigated` messages to simplify the unit test
written for 4c69d85.
---------
Signed-off-by: Brent Schroeter <contact@brentsch.com>
The same issue also affects check and other commands that support `--`,
but I'm not sure if it makes sense to document it everywhere.
Testing: Changes the help message, manual testing required.
Fixes: #43214
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
A published or vendored package will not have access to gstreamer.py.
Hence, we move the package list into libservo, and modify the remaining
usage of gstreamer.py (in mach) to read the same list.
Testing: Covered by CI testing, which involves building servo and the
macos dmg and windows installer.
Fixes: Part of #43145
---------
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
This is required to publish script_bindings, since all files used during
codegen need to be there.
It might also be possible to generate the bindings ahead of time and
vendor them in-tree, but this seems painful to setup from a CI
perspective.
Since there don't seem to be any other users in-tree we can just vendor
into the script-bindings directory.
`ply` is licensed under the BSD 3 clause, and WebIDL under MPL-2.0, with
the licenses available in our cargo package. Both tools won't end up in
`servo` since they are build-time dependencies, so I believe we don't
need to adjust the crate license, or configure `about.toml`.
Testing: Should be covered by existing tests. We don't test if this
allows vendored builds or published builds.
Fixes: Partial fix for #43145
---------
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
The CVE doesn't impact us, so we can ignore it safely. This improves the
comment above the ignored entry in deny.toml. We test our own code via
`clippy` and we aren't using the vulnerable type. Our dependencies could
in theory use it, but that seems rather unlikely.
Testing: test-tidy is tested in CI.
---------
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
As discussed on zulip we would like to rename `libservo` to `servo`
(again) before a future crates.io release.
Servo is a library, so the `lib` prefix is somewhat redundant. We
already renamed the binary of ServoShell to `servoshell`, to reduce
confusion of users of what servo is.
Note: This PR does not touch all occurrences of `libservo`. Specifically
CI job names remain untouched, since the risk of breaking something is
higher here, harder to test for and the name not user facing.
Testing: CI testing of this change should give us good confidence.
Manual testing of `./mach doc` and `./mach build` showed no issues on
macos. [Full try
run](https://github.com/jschwe/servo/actions/runs/22909562747)
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
We should only send previews of ordinary objects[^1] (i think that's the
correct term) objects to the devtools. The code is not designed to
handle other objects, which currently causes crashes.
Testing: This change adds a devtools test that crashes without this
change.
[^1]: https://tc39.es/ecma262/#ordinary-object
---------
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
This PR adds a test for `StepIn`, `StepOut` and `StepOver` hooks.
This test is intentionally designed to include all three `StepIn`,
`StepOut` and `StepOver` hooks in one test. This could be tested
separately but in a real use case one is mostly using these hooks
together in a single debugging session, not in isolation.
It is important we mirror that workflow. Also considering this area is
actively under development, it would be easier to catch regressions with
this flow test.
Testing: Added a new test
Fixes: Part of #36027
Signed-off-by: atbrakhi <atbrakhi@igalia.com>
Co-authored-by: eri <eri@igalia.com>
Add support for navigation requests ("navigateTo", "goBack", and
"goForward") over the Remote Debugging Protocol. These may be sent by a
UI client in response to user input (for example the address bar in the
Firefox inspector), or they can be used to automate navigation during
unit tests.
This currently only supports navigation within the URL domain at which
servoshell is initially launched, due to a bug in servo's
`BrowsingContextActor` implementation. (Unit tests covering a fix for
that issue will depend on this change.)
Testing: The behavior of all 3 new message types is covered by a new
test case—`test_navigation`—in the devtools unit test suite.
Fixes: #38668
---------
Signed-off-by: Brent Schroeter <contact@brentsch.com>
Co-authored-by: eri <eri@igalia.com>
This script automates the signing, packaging and notarization of
servoshell on macOS.
This is a first step towards: #40031 and #12532. While we could let a
maintainer code-sign and upload the signed release, probably this should
be integrated into CI, which would require additional work.
This script started out quite simple as part of `./mach package`.
However, since the script has access to secrets, it shouldn't be part of
mach (to minimize the amout of code that needs to be trusted).
We also needed to save state and be able to resume operations, since
notarizing can take quite long and the stapling needs to wait until
notarization has completed.
Since notarizing can take long (up to a day has been observed during
first tests), we save artifacts and the notarization ID, and add a
`--check-status` command that can be used to poll if notarization has
been finished.
Testing: Manually testing required. A signed and notarized `.dmg`
artifact has [been
uploaded](https://servo.zulipchat.com/#narrow/channel/500774-tsc/topic/Signing.20macos.20Servoshell/near/576256648)
to zulip, allowing others to verify the notarization worked.
---------
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
We had two `Info.plist` files. The maintained one is in the root
directory of this repository.
There is no reason for two plist files, so remove the unmaintained one.
Additionally, we also move the maintained version from the root
directory to the servoshell directory.
Testing: We don't test the contents of the plist file.
---------
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
See #42956. It's quite likely that this code has bitrotted and if this
feature is desired, should probably download the nightlies from GitHub
and also be updated to support our current packaging output.
Testing: This is just removing unused code from our build scripts.
Fixes: #42956.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
This is a preparation for publishing to crates.io. Changes include:
- Add `servo-` prefixes to avoid name collisions on crates.io
- Use `-` instead of `_` in package names.
- Rename the crates to their original names in Cargo.toml,
to keep the diff minimal
- Rename `media` to `servo-media-thread` to avoid name collision with
`servo-media` (originally from the media repository).
This is an outcome of the previous discussion at [#general > Switch
remaining git dependencies to
crates.io](https://servo.zulipchat.com/#narrow/channel/263398-general/topic/Switch.20remaining.20git.20dependencies.20to.20crates.2Eio/with/576336288)
Testing: This should be mostly covered by our CI, but some amount of
breakage is to be expected, since some package names could still be
referenced from scripts which are not tested or run in CI. [mach try
run](https://github.com/jschwe/servo/actions/runs/22502945949)
---------
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
Add `./mach print-env` to export the environment variables mach sets to
stdout and `./mach exec` to execute an arbitrary command in the custom
environment. This allows users to easily run custom commands, or tools
in the same environment as mach would create without adding support
every tool. Note: `./mach print-env` is only targeting UNIX shells for
now, although probably one could detect the shell and e.g. also support
PowerShell (in theory).
In principle, simple commands like `./mach cargo-fix` could be removed
and instead used via `./mach exec cargo fix`.
The execution of commands via `./mach exec my_command` (e.g. running
custom tools like cargo-flamegraph) still has some limitations, since
arguments that the user might have meant to pass to the command, might
be eaten by `./mach` (if mach expects that parameter, e.g. `--target
<triple>`. It's recommended to delimit explicitly by adding `--`., e.g.
`./mach exec --ohos -- cargo build --target aarch64-unknown-linux-ohos`.
Without the `--` delimiter, `./mach would interpret `--target` instead
of passing it to `cargo build`.
Testing: Manual testing of `./mach print-env --ohos`.
Fixes: #25473#38223
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
We don't use the CLOBBER file anywhere. The CLOBBER was introduced in
d03e52d240, but without any commit
message. Judging by the CLOBBER file in that commit, this was related to
the CI machines at the time. Should be safe to remove.
Testing: Well, this probably should be reviewed by someone who is
familiar with the background. Not covered by any tests.
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
As said in
https://github.com/servo/servo/issues/42803#issuecomment-3957052680,
there's been a weird discrepancy between running wdspec tests in:
1. local / Linux WPT workflow
2. WebDriver Try
For 2, it triggers FAIL/ERROR that never happen in 1. It is not
intermittent, but always happens.
This PR makes 2 have same behaviour as running locally: default number
of processes (CPU count. For self-hosted runner workflow, this is
double. Hyperthreading?), single chunk.
This improves the running time by 2 mins as well.
Testing: The test results now work same as Linux WPT and local.
https://github.com/servo/servo/actions/runs/22385441028/job/64795317878#step:11:552Fixes: #39097Fixes: #42803
---------
Signed-off-by: Euclid Ye <yezhizhenjiakang@gmail.com>
This cleans up some of the informational print statement during
`build_env()` to go to stderr instead.
This opens up stdout usage to print information to stdout for
consumption (in a follow-up PR)
Testing: Covered by `./mach build --ohos` in CI.
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
Currently, `script` and `devtools` use a node's unique id to identify it
across requests. The unique ID is part of a node's rare data field and
is really only meant for debugging. Instantiating it on a node causes
it's memory usage to go up significantly. Now, when the devtools ask for
information about a specific `Node` then they send the unique ID to
`script`, and the script thread then walks the whole DOM tree searching
for that specific ID. This happens here:
6d0b651218/components/script/devtools.rs (L142-L153)
So, in the worst case, all of the nodes in the tree now have a unique
ID. That's not great!
Also, when `script` notifies `devtools` about changes to a DOM node then
`devtools` expects a `NodeActor` to exist for that Node. The actor might
not exist if the inspector doesn't know about that node yet - that
happens when the user hasn't expanded their parent yet.
That is an oversight from https://github.com/servo/servo/pull/42601 and
causes problems now(https://github.com/servo/servo/issues/42784) because
for the longest time, `devtools` was mostly the one sending requests. Of
course, we could make `devtools` simply ignore updates for nodes that it
doesn't know about, but ideally we shouldn't send these updates in the
first place.
This change implements a lookup map on the `ScriptThread` that contains
all nodes that have been sent to the devtools inspector. The map allows
us to efficiently resolve a unique ID to a `Node` in O(1), without
creating unique IDs for the whole tree. It also allows us to only send
DOM updates for nodes that the inspector cares about.
For now, entries from the cache are not evicted unless the relevant
pipeline is closed. That reflects reality, because the inspector also
keeps using them forever.
In the future we will tell the inspector when nodes are removed from the
tree - then it can't interact with them anymore, and we can remove them
from the script-side map.
This is change is not all that complicated but it involves moving a lot
of code around, so feel free to ask for clarification when something is
unclear!
Testing: This change adds a test
Fixes part of https://github.com/servo/servo/issues/42784
---------
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
This should prevent recurring issues with exported WPT changes being
prevented from merging due to failing linting checks upstream.
Testing: Can't test WPT linting integration at this point in time.
Fixes: #40662
Signed-off-by: Josh Matthews <josh@joshmatthews.net>
The pause debugger screen should be shown for both pausing manually
(interrupt) and hitting a breakpoint.
Reuse the logic for pausing breakpoints to pause the debugger when the
user manually clicks the pause button.
Rename the pause event to interrupt to match the language of the
DevTools client and to avoid confusion with paused frames, which can
happen on interrupt or on a breakpoint.
https://github.com/user-attachments/assets/ceb0007d-0e57-44d6-a159-55980ff8b517
Testing: New DevTools test and manual testing.
Part of: #36027
cc @atbrakhi
---------
Signed-off-by: eri <eri@igalia.com>
Co-authored-by: atbrakhi <atbrakhi@igalia.com>
The inspector view allows modifying the attributes of DOM elements.
However, we lie to the devtools client: While it looks like the
attributes change, the changes are never actually applied to the DOM.
This change fixes that, and also makes it so attribute modifications
from non-inspector sources are shown in the inspector.
Testing: This change adds two tests
---------
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
