mirror of
https://github.com/servo/servo.git
synced 2025-08-06 14:10:11 +01:00
effd5a3107
Fixes the test case `/_mozilla/css/css-transition-cancel-event .html`, which was failing under a specific circumstance. The observed sequence of events during the failing test run looks like this: 1. Transitions start in `div1` and `div2`. 2. `div1` generates a `transitionend` event. 3. The `transitionend` event handler removes `div2` from DOM, cancelling its ongoing transition. 4. `div2` is supposed to generate a `transitioncancel` event in a timely manner, which it does not. The test fails as a result. What is going on here? Here's a possible explaination: 1. During one invocation of `ScriptThread::handle_msgs`... 2. In step 2, `ScriptThread::update_animations_send_events` -> `Document ::update_for_new_timeline_value` detects the completion of the transition, and in response, pends the `transitionend` event. 3. In step 3, `ScriptThread::update_animations_send_events` -> `Animations::send_pending_events` calls the `transitionend` handler. 4. The `transitionend` event handler removes `div2`, thereby cancelling its ongoing transition and triggering a reflow. 5. Reflow takes place. During this, `Animations::do_post_reflow_update` -> `Animations::handle_canceled_animations` pends the `transitioncancel` event (precursor to step 4). 6. Having discovering that there was no running animation, `Animations:: do_post_reflow_update` calls `self.update_running_animation_presence (_, false)`, which sends `AnimationState::NoAnimationsPresent`. 7. The invocation of `ScriptThread::handle_msgs` ends, and another starts. It blocks waiting for events. 8. Meanwhile, the compositor receives `AnimationState:: NoAnimationsPresent` and stops further generation of animation ticks. 9. With no events to wake it up, the script thread is stuck waiting despite having the pending `transitioncancel` event (step 4). The HTML specification [says][1] that "an event loop must continually run [...] as long as it exists" and does not say it can block if there is nothing to do. Blocking is merely optimization in a user agent implementation. Pending animation-related events must be processed every time a "rendering opportunity" arises unless the user agent has a reason to believe that it "would have no visible effect". Skipping the processing of animation-related events would have visible effect if such events are indeed present. The correct implementation in Servo, therefore, would be to request more animation ticks so that such events are processed in a subsequent tick. [1]: https://html.spec.whatwg.org/multipage/#event-loop-processing-model |
||
|---|---|---|
| .. | ||
| allocator | ||
| atoms | ||
| background_hang_monitor | ||
| bluetooth | ||
| bluetooth_traits | ||
| canvas | ||
| canvas_traits | ||
| compositing | ||
| config | ||
| config_plugins | ||
| constellation | ||
| deny_public_fields | ||
| derive_common | ||
| devtools | ||
| devtools_traits | ||
| dom_struct | ||
| domobject_derive | ||
| embedder_traits | ||
| fallible | ||
| geometry | ||
| gfx | ||
| gfx_traits | ||
| hashglobe | ||
| jstraceable_derive | ||
| layout | ||
| layout_2020 | ||
| layout_thread | ||
| layout_thread_2020 | ||
| layout_traits | ||
| malloc_size_of | ||
| media | ||
| metrics | ||
| msg | ||
| net | ||
| net_traits | ||
| pixels | ||
| profile | ||
| profile_traits | ||
| rand | ||
| range | ||
| remutex | ||
| script | ||
| script_layout_interface | ||
| script_plugins | ||
| script_traits | ||
| selectors | ||
| servo | ||
| servo_arc | ||
| size_of_test | ||
| std_test_override | ||
| style | ||
| style_derive | ||
| style_traits | ||
| to_shmem | ||
| to_shmem_derive | ||
| url | ||
| webdriver_server | ||
| webgpu | ||
| webrender_surfman | ||
| webrender_traits | ||