Re: [csswg-drafts] [resize-observer] Following spec logic results in many more "resize loop error notifications" than are sent by Chrome (#6610)

I believe I came to the same conclusion as @atotic on the WPT [issue thread](https://github.com/web-platform-tests/wpt/issues/30708#issuecomment-918846528) - the depth is equivalent after the modification during dispatch, the notification does not immediately fire, and an error is queued up. The `setup({allow_uncaught_exception: true});` line at the beginning prevents this from failing the test. Then when another frame is produced (we request a new frame after we queue the error event up, to make sure they are cleared out in the next frame), the observation is delivered, which causes the test to pass. This is in accordance with this line:

> An error is generated if notification loop completes, and there are undelivered notifications. Elements with undelivered notifications will be considered for delivery in the next loop.

I think the spec is close, but probably needs to specify whether skipped observations should be flushed by the UA by queuing up another frame or if it's more of a best effort and can be delivered more lazily. Without thinking too hard about it, I think I would side on Blink's current behavior, but I can see how maybe this produces a different kind of infinite loop. But at least Blink's behavior would be more deterministic for authors.

In any case, the test(s) should probably be split out into separate files for clarity and to scope the usage of uncaught exceptions as tightly as possible.

-- 
GitHub Notification of comment by dlibby-
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6610#issuecomment-919647671 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 15 September 2021 02:26:14 UTC