w3c / w3c/csswg-drafts

[cssom-view] Handling of scrollend events seems wrong

Open
#8,396 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

cssom-view-1
Dominant language
Bikeshed
Stars
4.9k
Forks
816
PR merge metrics
PR metrics pending

Description

https://w3c.github.io/csswg-drafts/cssom-view/#scrolling-events

Each Document has an associated list of pending scrollend event targets, initially empty.

Whenever scrolling is completed, the user agent must run these steps:​

If scrolling was done on a viewport, let doc be the viewport’s associated Document and target be the viewport\. Otherwise, scrolling is done on an element and let doc be the element’s node document and target be the element\.

If target is already in doc’s pending scrollend event targets, abort these steps\.

Append target to doc’s pending scrollend event targets\.

For each item target in doc’s pending scrollend event targets, in the order they were added to the list, run these substeps:​

    If target is a Document, fire an event named scrollend that bubbles at target\.

    Otherwise, fire an event named scrollend at target\.

Empty doc’s pending scrollend event targets\.

This setup doesn't make sense to me. As specified, the "pending scrollend event targets" can be optimized away since you add a single entry to it, then immediately process it, then empty the list, in the same algorithm.

But, at what point does the UA determine that scrolling is completed? If it's not done in "run the scroll steps", the spec may fire scrollend first and scroll afterwards. Or, if "scrolling is completed" happens in parallel (off-main-thread), then the spec says to fire an event in a situation where would instead have to queue an event to fire the event (which the spec doesn't say to do).

For scroll events, the "pending scroll event targets" list can be populated in parallel, and the "run the scroll steps" is called from HTML's event loop: https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering

I think the appropriate fix here is to move the "fire an event" and emptying of the queue for scrollend into "run the scroll steps" algorithm, after it has dealt with any scroll events.

cc @emilio @dlrobertson @argyleink

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Read the linked CSSOM View scrolling-events algorithm and compare it with HTML's update-the-rendering and run-the-scroll-steps algorithms. Trace when scrolling completion, scroll events, and scrollend events are processed; done means the specification clearly defines their ordering and event-queue handling.

Written by the indexing model from the issue text.

Assessment

Tech stack
css
Domain
documentation, web-dev
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.