Instead of running "update the rendering" at every IPC message, only run
it when a timeout has occured in script. In addition, avoid updating the
rendering if a rendering update isn't necessary. This should greatly
reduce the amount of processing that has to happen in script.
Because we are running many fewer calls to "update the rendering" it is
reasonable now to ensure that these always work the same way. In
particular, we always run rAF and update the animation timeline when
updating the ernder
In addition, pull the following things out of reflow:
- Code dealing with informing the Constellation that a Pipeline has
become Idle when waiting for a screenshot.
- Detecting when it is time to fulfill the `document.fonts.ready`
promise.
The latter means that reflow can never cause a garbage collection,
making timing of reflows more consistent and simplifying many callsites
that need to do script queries.
Followup changes will seek to simplify the way that ScriptThread-driven
animation timeouts happen even simpler.
Testing: In general, this should not change testable behavior so much,
though it
does seem to fix one test. The main improvement here should be that
the ScriptThread does less work.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
- Updating the WheelEvent initialization to correctly handle keyboard
modifiers when the wheel event is triggered. The changes ensure that the
modifiers (Ctrl, Alt, Shift, Meta) are properly set based on the current
state of the keyboard when the wheel event is created. This is
particularly important for scenarios where the wheel event is influenced
by key presses, such as scrolling with the Ctrl key pressed to zoom in
or out.
- Updating the `screen_point` and `client_point` as it was always 0,0
before. Now, it shows the correct position of the mouse pointer while
triggering the wheel event.
Test: Manual Test case and existing WPT tests
(classic/perform_actions/wheel.py[test_scroll_with_key_pressed])
Fixes: #37827
Signed-off-by: abdelrahman1234567 <abdelrahman.hossameldin.awadalla@huawei.com>
These changes reduce the number of times we need to query layout for the
same information when creating mouse/pointer events.
Testing: No new tests required for maintaining existing behaviour.
Signed-off-by: Josh Matthews <josh@joshmatthews.net>
Note: The WheelEvent interface supports rotation in all 3 spatial
dimensions. This implementation only supports two due to limitations
in the Glutin compositor.
The wheelevent interface is a dom interface that triggers for any
attached device that can rotate in one or more spatial dimensions.
Traditionally this is the mouse wheel though other devices could be
used as well. E.g. the trackball on a trackball mouse.
