There are currently five places that scroll offsets are stored:
- DOM: A set of scroll offsets used for script.
- Layout: An array of scroll offsets that is used for tracking
layout-side scroll offsets.
- Layout: The scroll offsets stored in the `ScrollTree`. These are
currently unset and unused.
- Compositor: The scroll offsets stored in the `ScrollTree` mirrored
from layout.
- WebRender: The scrolled offsets stored in the WebRender spatial tree.
This change is the first step in combining the first three into the
layout `ScrollTree`. It eliminates the extra array of scroll offsets
stored in layout in favor of the storing them in the `ScrollTree`. A
followup change will eliminate the ones stored in the DOM.
- In addition the `ScrollState` data structure is eliminated as these
are
now stored in a `HashMap` everywhere when passing them via IPC.
- The offsests stored in layout can now never scroll past the boundaries
of the scrolled content.
Testing: This should not change behavior and is thus covered by existing
WPT tests.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: stevennovaryo <steven.novaryo@gmail.com>
The compositor was accepting scroll offsets from the ScriptThread
without checking their boundaries. In some cases this could cause a
temporary discrepancy with the rendered scroll offset. This change makes
it so that all offset updates for scroll ayers in the compositor do not
scroll past the scroll boundaries of the node.
Testing: Two new tests pass with this change:
- `/css/css-position/sticky/position-sticky-left-003.html`
- `/css/css-position/sticky/position-sticky-top-003.html`
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Add a missing step in hit test retry
[(comment)](0d02b61f72 (r2131567216)).
cc: @xiaochengh , @kongbai1996
---------
Signed-off-by: batu_hoang <longvatrong111@gmail.com>
Use own `ViewportDescription` to `clamp()` initial_scale.
If use `self` it will use current module `ViewportDescription`, which is
old one because new `ViewportDescription` is not set yet.
Testing: Tested Locally
Fixes: #37338
Signed-off-by: Shubham Gupta <shubham13297@gmail.com>
Follow up to [hit_test failed occasionally when the touch event is
sent](https://github.com/servo/servo/issues/35788#top) and
https://github.com/servo/servo/issues/36676#issuecomment-2882917136,
this PR adds a retry for hit tests with expired epoch in result.
Hit tests with outdated epoch mean it is too early to perform the hit
test.
Solution: retry hit test for the event on the next webrender frame.
The retry should guarantee that:
- Keep the correct order of events
- Retry time is not too long
Test cases: `./mach test-wpt --product servodriver -r
tests\wpt\tests\webdriver\tests\classic\element_click\events.py`
cc: @xiaochengh , @yezhizhen
---------
Signed-off-by: batu_hoang <longvatrong111@gmail.com>
Implement missing synchronization in `dispatch_actions` of `WebDriver`.
https://w3c.github.io/webdriver/#dispatching-actions
> The user agent event loop has spun enough times to process the DOM
events generated by the last invocation of the >[dispatch tick
actions](https://w3c.github.io/webdriver/#dfn-dispatch-tick-actions)
steps.
- Add a way for `ScriptThread` to notify `WebDriver` about the
completion of input commands.
- Add a `webdriver_id` field for `InputEvent`. `ScriptThread` uses it to
distinguish WebDriver events and sends notification.
Tests:
`./mach test-wpt --product servodriver -r
tests\wpt\tests\webdriver\tests\classic\element_click\events.py` pass if
`hit_testing` pass. Check
[issue](https://github.com/servo/servo/issues/36676#issuecomment-2882917136)
cc: @xiaochengh
---------
Signed-off-by: batu_hoang <longvatrong111@gmail.com>
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Martin Robinson <mrobinson@igalia.com>
When multiple WebViews are updating scroll events, instead of taking the
list of `WebView`s to avoid a double-borrow, batch scroll events into a
single transaction. This should make processing slightly more efficient
and avoids having to take the vector of WebViews.
Testing: No behavior change here and this aspect of WebView interaction
is untestable currently.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
After `InputEvent::Touch` processed by Script, it sends
`TouchEventProcessed` back to Constellation, which goes through hit-test
etc. and loops back to Script again. However,
`WebViewRenderer::simulate_mouse_click` should not send
`MouseButtonAction::Click` due to #36413
Testing: Manually tested by converting mouse to touch
cc @jdm @xiaochengh
Signed-off-by: Euclid Ye <yezhizhenjiakang@gmail.com>
Previously, when processing animations, the compositor would sent a tick
message to each pipeline. This is an issue because now the
`ScriptThread` always processes rendering updates for all `Document`s in
order to ensure properly ordering. This change makes it so that tick
messages are sent for an entire WebView. This means that each
`ScriptThread` will always receive a single tick for every time that
animations are processed, no matter how many frames are animating. This
is the first step toward a refresh driver.
In addition, we discard the idea of ticking animation only for
animations and or only for request animation frame callbacks. The
`ScriptThread` can no longer make this distinction due to the
specification and the compositor shouldn't either.
This should not really change observable behavior, but should make Servo
more efficient when more than a single frame in a `ScriptThread` is
animting at once.
Testing: This is covered by existing WPT tests as it mainly just improve
animation efficiency in a particular case.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
There is a `WebView` in libservo (new) and a `WebView` in compositing
(old). Nowadays, the "real" `WebView` is the one in the libservo. The
`WebView` in `compositing` is really about rendering the contents of a
`WebView` from libservo. In addition there is also a trait exposed by
the compositor called `RendererWebView` which is a way for the
compositor to talk to libservo without a circular dependency.
This changes does some renames to make things clearer and so that there
is One Less WebView™:
- `compositing::WebView` -> `compositing::WebViewRenderer` (this is the
same kind of naming as `ServoRenderer`).
- `compositing::RendererWebView` -> `compositing::WebViewTrait`
Testing: This is just a couple renames so should be covered by existing
tests.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
2025-04-21 08:47:39 +00:00
Renamed from components/compositing/webview.rs (Browse further)
