When reloading, the pipeline is closed before we get the chance to set
accessibility inactive, which we do for pipelines which stick around in
the bfcache. We don't need to panic if we're trying to de-activate
accessibility and the pipeline is already closed.
Trying to activate accessibility on a closed pipeline is an error we
should investigate, but probably also not a panic-worthy condition.
Testing: Not sure how to test this beyond manual testing. Manual
testing: run servoshell with `--pref accessibility_enabled` and reload
any page.
Signed-off-by: Alice Boxhall <alice@igalia.com>
Follow-up to #44443.
This helps investigating the cold-start timeline, and could be used
by tooling to A/B compare branches affecting the cold-start time.
Additionally also change the `handle_request::select` span, so that we
can see the blocked time (which was probably what was intended), since
the actual time spent on recv after select is insignificant.
Testing: Tracing output is not covered by automatic tests.
---------
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
This moves Servo closer to the focus parts of the HTML specification.
The behavior should be the same as before, but now the code in `script`
matches the structure of the specification.
The main goal is to set us up for:
- Firing focus events in the right order on nested documents
- A proper implementation of the unfocusing steps.
Testing: This should not change behavior so is covered by existing
tests.
Signed-off-by: Martin Robinson <mrobinson@fastmail.fm>
Co-authored-by: Martin Robinson <mrobinson@fastmail.fm>
This "JSContextify"s part of DocumentEventHandler, namely the actions
from `handle_pending_input_events`.
Additionally, we also switch the MouseEvent and KeyboardEvent. This does
not change yet PointerEvent and some other events used to keep the diff
reasonable.
Testing: This is part of the JSContextify work that is fundamental and
tested by WPT.
---------
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
This introduces a `ScriptToEmbedderChan` property on `LayoutThread`,
which is used to send accessibility updates directly to the embedder.
Follow-up to https://github.com/servo/servo/pull/42338.
Testing: Covered by existing tests.
Signed-off-by: Alice Boxhall <alice@igalia.com>
This change introduces the `accessibility_tree` module, containing code
to build an in-memory representation of a very basic accessibility tree
for web contents. Currently, the tree for a given document contains:
- a `RootWebArea` which has the document root node as its sole child,
- an `Unknown` node for the root DOM node,
- a `GenericContainer` node for each DOM element, and
- a `TextRun` node for each text node.
This allows us to make basic assertions about the tree contents in the
`accessibility` test by doing a tree walk to find text nodes and
checking their contents.
Right now, the tree is rebuilt from scratch when accessibility is
enabled and when a navigation occurs (via
`Constellation::set_frame_tree_for_webview()` sending
`ScriptThreadMessage::SetAccessibilityActive`); it's not responsive to
changes in the page.
This change also changes the way we handle updating the graft node
between the webview's accessibility tree and its top level pipeline's
accessibility tree.
Previously, `Constellation::set_frame_tree_for_webview()` would send a
`ConstellationToEmbedderMsg::DocumentAccessibilityTreeIdChange` method
informing the webview of the accesskit TreeId of the top-level pipeline.
However, this resulted in flaky timing as we couldn't depend on that
message being handled before the message containing the TreeUpdate from
the WebContents, which would lead to a panic as the new TreeId wasn't
grafted into the combined tree yet.
This change introduces an epoch value which flows from the
ConstellationWebview, where it's updated every time the
`active_top_level_pipeline_id` changes, to the layout accessibility
tree, and finally to the webview with each TreeUpdate. Whenever a
TreeUpdate arrives at the webview which has a newer epoch than the last
known epoch, the webview-to-contents graft node is updated before the
TreeUpdate is forwarded. If a TreeUpdate arrives at the webview with an
epoch _older_ than the last known epoch, it's dropped, as it must be for
a no-longer-active pipeline.
Fixes: Part of #4344
---------
Signed-off-by: delan azabani <dazabani@igalia.com>
Signed-off-by: Alice Boxhall <alice@igalia.com>
Co-authored-by: delan azabani <dazabani@igalia.com>
Co-authored-by: Luke Warlow <lwarlow@igalia.com>
Moved devtools_wants_updates from GlobalScope to Window
Testing: Compiles cleanly. ```./mach test-devtools``` gives different
results each time, ```./mach test-devtools
test_sources_list_with_data_inline_classic_script``` always pass though.
Fixes: #44106
Signed-off-by: Sabb <sarafaabbas@gmail.com>
Signed-off-by: Abbas Olanrewaju Sarafa <109840351+sabbCodes@users.noreply.github.com>
There are two times that Servo needs to ask other `Document`s to either
focus or blur.
- During processing of the "focusing steps". When a new element gains
focus this may cause focus to be lost or gained in parent `<iframe>`s.
- When calling `focus()` on a DOM Window from another origin.
In both of these cases we need to request that a `Document` gain or lose
focus via the Constellation, but in the second case we may have a
`BrowsingContextId` of the `<iframe>` gaining focus and a
`FocusSequence`. This change splits those cases into two kinds of
messages.
Finally, run the entire focusing steps when calling `window.focus()`
instead of going to the constellation immediately. This will be
important in a followup changes where messaging order is made more
consistent.
Testing: This should not change behavior so is covered by existing
tests.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
DevTools was collecting CSS rules by walking stylesheets and matching
selector text. This ignored cascade order and did not correctly handle
rules inside layer blocks.
This change uses computed values (rule tree) to get the actual applied
rules in cascade order. It then maps those rules back to CSSStyleRule
using the declaration block identity, and walks the CSSOM to get
selector text and layer ancestry.
This fills ancestor_data with layer names and lets the inspector show
layered rules correctly.
Testing:
- Verified using the minimized testcase from the issue
- Verified on https://www.sharyap.com/
- Confirmed that rules inside layer blocks are now shown with correct
order and hierarchy.
Fixes: #43541
Signed-off-by: arabson99 <arabiusman99@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>
A lot (and I mean, really a lot) depends on these constructors.
Therefore, this is the one spaghetti ball that I could extract and
convert all `can_gc` to `cx`. There are some new introductions of
`temp_cx` in the callbacks of the servo parser, but we already had some
in other callbacks.
Part of #40600
Testing: It compiles
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
This continues the work to split up the large DOM structs. In this case
we create a helper struct to store focus-related state much like
`DocumentEventHandler`.
Testing: This is mostly code motion, so should be covered by existing
tests.
Fixes: #43720
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
`HTMLOrSVGElement#focus` specifies the "scroll into view" steps should
be run after focusing. This was happening implicitly as part of the
`Document`'s implementation of the "focusing steps." That behavior is
not in the specification, so this change moves the scrolling call to
where it is specified. Along with making the code match the
specification, this change simplifies it as well.
Testing: This should not modify behavior, so existing tests should
suffice.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
For years Servo has had the concept of a focus transaction which was
used only to allow falling back to focusing the viewport when focusing a
clicked element failed. As this concept isn't part of the specification,
this change removes it.
Instead, a `FocusableArea` (a specification concept) is passed to
the `Document` focusing code. A `FocusableArea` might also be the
`Document`'s viewport.
As part of this change, some focus-related methods are moved to `Node`
from `Element` as the `Document` is not an `Element`. This brings the
code closer to implementing the "focusing steps" from the specification.
Testing: This should not change behavior and is thus covered by existing
tests.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
This set of changes introduces a type matching the spec's "target
snapshot params" and uses it as part of determining the origin of new
documents. This has a side benefit of making our sandbox flag
determination more accurate, which leads to a bunch of sandboxing tests
passing as well as some new failures due to spec confusion about
origins.
Testing: Many new passing tests.
Part of the long road to #43149
---------
Signed-off-by: Josh Matthews <josh@joshmatthews.net>
We were previously conflating the concept of a navigation request's
origin with the origin of the resulting document. These changes ensure
that the navigation request's origin is based on the navigation
initiator's origin, and the document's origin is not computed until
after the navigation response is received.
The most visible effect of these changes is that documents in sandboxed
iframes now correctly have an opaque origin.
Testing: Lots of new passing tets.
Signed-off-by: Josh Matthews <josh@joshmatthews.net>
Requires communication between the script thread and the constellation
to be able to retrieve the origin of a cross-origin document. However,
in the fast-path where the document resides in the same script-thread,
we use the `frame_element` instead.
If no CSP list is active, then we skip all this logic, to have a minimal
impact on document navigation.
Part of #4577Fixes#36468
---------
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
Signed-off-by: Tim van der Lippe <TimvdLippe@users.noreply.github.com>
Both `Window::load_url` and `ScriptThread::navigate` implement parts of
the same navigate algorithm from the HTML spec
(https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigate).
`ScriptThread::navigate` had only one caller: `Window::load_url`.
This merges both methods into a single `navigate` function in
`navigation.rs`, which is the appropriate home for navigation logic. All
previous callers of `Window::load_url` now call `navigation::navigate`
directly.
Testing: This is a pure refactor with no behaviour changes, so no new
tests are needed. Existing tests cover the navigation paths affected.
Fixes: #43494
---------
Signed-off-by: thebabalola <t.babalolajoseph@gmail.com>
This update makes service workers properly show up in DevTools and
behave more like dedicated workers.
- Added an is_service_worker field to DevtoolsPageInfo so the devtools
server can tell service workers apart from dedicated workers
- Triggered a NewGlobal message when a service worker is created in
serviceworker_manager.rs, similar to what already happens for dedicated
workers
- Routed service workers to root.service_workers so they appear under
"Service Workers" in about:debugging instead of "Other Workers"
- Implemented listServiceWorkerRegistrations with the expected response
format (activeWorker, installingWorker, waitingWorker, evaluatingWorker)
to match Firefox’s LegacyServiceWorkersWatcher
- Added support for getPushSubscription in WorkerActor, currently
returning subscription: null
Enabled the service_worker target type in the watcher’s SessionContext
and handled watchTargets("service_worker")
Testing
Start Servo with:
`RUST_LOG="error,devtools=debug" ./mach run --
--pref=dom_serviceworker_enabled --devtools=6080
"https://mdn.github.io/dom-examples/service-worker/simple-service-worker/"
`
In Firefox, go to about:debugging and connect to localhost:6080
Confirm the service worker shows up under "Service Workers"
Fixes#43574
---------
Signed-off-by: CynthiaOketch <cynthiaoketch6@gmail.com>
The commit contains several related changes:
* iframes that load javascript: URLs as part of the initial insertion
(ie. `<iframe src='javascript:...'>`) get a synchronous load event
dispatched
* javascript: URL evaluation that does not result in a string no longer
treated like a 204 response
* iframes that perform a javascript: URL navigation that does not result
in a new document no longer block the parent document load event
Testing: Lots of new tests passing.
Fixes: #24901
---------
Signed-off-by: Josh Matthews <josh@joshmatthews.net>
There were two issues here:
1. We weren't firing the `load` event when we would show an error page
because of a CSP failure. This is to avoid web pages knowing wheter a
page has failed because of CSP.
2. We were reporting the violations in the wrong global. We shouldn't
fire these in the global of the child, but instead in the parent.
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
- canvas
- constellation_traits
- canvas_traits
- constellation
Testing: This should not change any behaviour.
---------
Signed-off-by: Euclid Ye <yezhizhenjiakang@gmail.com>
Currently, the `web_font_finished_loading_callback` sends a
`ScriptThreadMessage::WebFontLoaded` message regardless of whether web
font loading succeeds or not, which leads to dirtying all nodes in
`script_thread.rs`. This creates unnecessary reflow. This PR removes the
boolean field from the `WebFontLoaded` message and only sends the
message when the web font loading is successful.
Testing: Existing WPT tests
Signed-off-by: Minghua Wu <michael.wu1107@gmail.com>
Follow up of #43526. This addresses Nico's comment:
https://github.com/servo/servo/pull/43526#issuecomment-4104953308
- `bluetooth_traits` -> `servo_bluetooth_traits`
- `base` -> `servo_base`
- `bluetooth` -> `servo_bluetooth`
- `background_hang_monitor` -> `servo_background_hang_monitor`
Testing: This should not change any behaviour.
---------
Signed-off-by: Euclid Ye <yezhizhenjiakang@gmail.com>
We now check for this header and corresponding logic. The WPT tests
mostly pass, but rely on the `contentDocument` of the iframe to be
`null`. This is not something we did before, which means that iframes
were able to access the contents of error pages.
Instead, we now mark the document as internal with an opaque origin
according to the spec [1]. We shouldn't do this post-fact, but is
required since we first need to construct the document and enter its
realm, before we determine that it is an invalid document.
Fixes#16103
[1]:
https://html.spec.whatwg.org/multipage/document-lifecycle.html#navigate-ua-inline
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
Pass `&mut JSContext` to `CustomElementReaction::invoke` and
`upgrade_element` algorithm.
Testing: A successful build is enough
Part of #40600
Signed-off-by: Gae24 <96017547+Gae24@users.noreply.github.com>
script: Add navigation and traversal task source
Testing: This shouldn't be something that's observable through tests, so
a successful build is enough to verify the change.
Fixes: #43497
---------
Signed-off-by: Jayanta Pradhan <pradhanjayanta91@gmail.com>
This pulls one bit of navigation logic out into a method that is easier
to cross-reference against the spec, and drops a bunch of custom logic
that is better served by the existing LoadOrigin infrastructure.
Testing: Existing WPT coverage is sufficient.
Signed-off-by: Josh Matthews <josh@joshmatthews.net>
This is no longer present in the spec. Instead, the
`process_request_body` is the new way. These two
methods were called right after each other and there was only 1
implementation in `htmlvideoelement`. That implementation is now moved
to `process_request_body` and hence we can remove the unnecessary
method.
Testing: It compiles
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
This moves some easy elements in Script from IpcChannel and related
methods to GenericChannel and related methods and some callbacks.
Testing: This will be covered by WPT if the channels behave differently.
---------
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
in #42336, we added a
[Servo](https://doc.servo.org/servo/struct.Servo.html)-global API for
controlling whether accessibility is active. the idea was that when the
embedder activates accessibility, all webviews and documents activate
accessibility and start sending AccessKit tree updates, and vice versa
when they deactivate.
we found a problem with this approach in #42338. global activation of
accessibility makes it too easy to accidentally cause a panic in
AccessKit, and harder than it needs to be for embedders to learn that
they are responsible for grafting each webview’s subtree into their main
AccessKit tree as soon as accessibility is activated. this is due to an
invariant of the AccessKit subtree API: if a subtree starts sending
updates before the graft node is created, the program panics.
this patch reworks accessibility activation to make it per-webview. by
requiring embedders to explicitly activate accessibility for a webview,
we can communicate the AccessKit invariant via our API docs.
Testing: this patch includes an initial accessibility test in libservo
Fixes: part of #4344, extracted from our work in #42338
---------
Signed-off-by: Alice Boxhall <alice@igalia.com>
Signed-off-by: delan azabani <dazabani@igalia.com>
Co-authored-by: Alice Boxhall <alice@igalia.com>
Add the cx parameter to `fn process_response` in the
`FetchResponseListener` trait and the traits that that interface change
requires. Chose to add it as the first parameter, following the same
order that `FetchResponseListener::process_response_eof` uses.
Testing: Checked that servo builds locally as well as `./mach fmt` and
`./mach test-tidy`. I don't think more tests are needed as we are not
introducing new functionality
Fixes: #42840
---------
Signed-off-by: Javier Olaechea <pirata@gmail.com>
The console actor sends `Eval` via debugger.js, not `EvaluateJS`.
Workers only handled `EvaluateJS` which was never sent. We would want to
use `Eval` for workers as well. The worker evaluation was already
non-functional.
One more motivation behind not keeping this legacy path is because it
requires passing `None` for all new fields added to
`EvaluateJSReplyValue`, that is extra burden.
Testing: All existing tests are passing.
Signed-off-by: atbrakhi <atbrakhi@igalia.com>
This is a hot path:
- there is a lot of processing in `handle_pending_input_events`: JS
realm entry, temporary variable creation, value assignment etc.
- we acquire a RAII guard before calling the function.
If the event queue is empty, this would result in unnecessary overhead
on the hot path.
We skip all above work in this case.
Testing: This is an optimization that should not change visible
behaviour,
thus covered by all the testdriver tests.
---------
Signed-off-by: Euclid Ye <yezhizhenjiakang@gmail.com>
ScriptWindowProxies's find_window_proxy and get methods are exactly the
same; remove the latter.
Testing: Existing WPT tests should cover the script_thread.rs change
Fixes: https://github.com/servo/servo/issues/43251
Signed-off-by: Simon Martin <simon@nasilyan.com>
The spec expects us to check for render blocking (among some other
state) before we start procesing a document. Therefore, add those checks
and also check in the
stylesheet loader that we should only do so when we are allowed to do
so.
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
This option controls whether progressive web metrics are printed to the
system console, which is essentially the purpose of
`DiagnosticsLogging`. This makes the API a bit more uniform.
Testing: We do not really have automated testing for this kind of
feature of the API.
Fixes: This is part of #34967.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Initial work to support scopes in the debugger. They don't show at the
moment since we are not processing variables yet. Depends on #43166.
Testing: Ran `mach test-devtools` and manual testing.
Part of: #36027
Signed-off-by: eri <eri@igalia.com>
Co-authored-by: atbrakhi <atbrakhi@igalia.com>
We send back input events handling results in batch. This reduces IPC,
and make the following **TODO** possible in a follow-up.
Testing: I hope existing tests results won't change.
Part of
https://github.com/servo/servo/issues/43136#issuecomment-4031915873
**TODO**: We have not done
> collect ids and send back a reply for each of them once the coalesced
event has been handled.
yet.
---------
Signed-off-by: Euclid Ye <yezhizhenjiakang@gmail.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>
Pass `ListFrames` back to devtools
Testing: existing test passes
Fixes: part of #36027
Signed-off-by: atbrakhi <atbrakhi@igalia.com>
Co-authored-by: eri <eri@igalia.com>
