Repository navigation
[cssom-view-1] Missing tasks in parallel steps in CSSOM View Module Level 1 #12940
Description
While crawling CSSOM View Module Level 1, the following algorithms fire an event, or resolve or reject a Promise, within a step that runs in parallel without first queuing a task:
- The perform a scroll of a box algorithm resolves/rejects a promise directly in a step that runs in parallel
- The perform a scroll of a viewport algorithm resolves/rejects a promise directly in a step that runs in parallel
- The scroll a target into view algorithm resolves/rejects a promise directly in a step that runs in parallel
See Dealing with the event loop in the HTML specification for guidance on how to deal with algorithm sections that run in parallel.
This issue was detected and reported semi-automatically by Strudy based on data collected in webref.
Activity
emilio commentedon Oct 13, 2025
cc @mustaqahmed @flackr
nwidynski commentedon Oct 9, 2026
@mustaqahmed @flackr I have a use case that depends on this for
scrollIntoView({container: "nearest"}). A virtualized list re-targets a row that moves during the scroll as rows mount, from code that only has the element. Before each new call it needs to know whether someone else, say ascrollTo({top: 0}), interrupted the running scroll, since its own call interrupts it as well.If the per-box promises were awaited with wait for all instead of in parallel, the interruption would be visible at the next microtask checkpoint, as the spec already requires for
element.scrollTo(). With a queued task, as Chrome does today (crbug.com/571658269), the list only sees it in time if that task happens to run in time.