Bug 204465
| Summary: | `unhandledrejection` event is fired later than specified | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | mike |
| Component: | DOM | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | ahmad.saleem792, ap, bfulgham, cdumez, rniwa, webkit-bug-importer, ysuzuki |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari 13 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
mike
## Steps to reproduce
(1) Create a document with the following markup
<!DOCTYPE html>
<meta charset="utf-8">
<body>
<script>
addEventListener('unhandledrejection', () => {
console.log('unhandledrejection')
});
document.body.addEventListener('readystatechange', () => {
console.log('readystatechange');
});
</script>
</body>
(2) Open the document
(3) Open the developer's console
A live demonstration is available at [1].
## Expected result
Three messages should be printed in the following sequence:
readystatechange
unhandledrejection
readystatechange
## Actual result
Three messages are printed in the following sequence:
unhandledrejection
readystatechange
readystatechange
Explanation of expected behavior: The script is executed immediately while
parsing is ongoing, and "cleaning up after running script" [2] involves
queueing a task on the DOM manipulation task source to fire the
`unhandledrejection` event. Parsing then completes, immediately transitioning
the document's readiness state to "interactive," and queuing another task on
the DOM manipulation task source to transition the state to "complete."
WebKit's bug does not appear to be a regression. It seems to have exhibited the
incorrect event sequence since the `unhandledrejection` event was introduced in
Safari version 11.1.
A test asserting the expected behavior is under review in the
web-platform-tests project at [3].
[1] https://output.jsbin.com/wozetohudo/quiet
[2] https://html.spec.whatwg.org/multipage/webappapis.html#clean-up-after-running-script
[3] https://github.com/web-platform-tests/wpt/pull/20329
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/57443584>
Ryosuke Niwa
I don't get it. The test case presented here doesn't log anything. I guess it's missing Promise.reject().
If I open https://jsbin.com/wozetohudo/5/edit?html,output in Chrome or Firefox, the order of operations is readystatechange, readystatechange, unhandledrejection.
mike
> The test case presented here doesn't log anything. I guess it's missing
> Promise.reject().
Yes, sorry about that! (Though hopefully even the broken example still
logs `readystatechange` a couple times.)
> If I open https://jsbin.com/wozetohudo/5/edit?html,output in Chrome or
> Firefox, the order of operations is readystatechange, readystatechange,
> unhandledrejection.
This may be an artifact of loading the page over a network connection.
Additionally, the JSBin service is presenting the test case with some
modifications and in the context of an iframe. They offer a feature to
disable this (via the `/silent` path suffix), but it doesn't seem to be
working here.
This was also reported during triage of my report to Chromium [1]. Perhaps
this is the result of some shared code.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=1027230
Ahmad Saleem
Safari TP 151 still fail this test:
https://wpt.fyi/results/html/webappapis/scripting/processing-model-2/unhandled-promise-rejections/promise-rejection-event-during-parse.html?label=experimental&label=master&aligned
Chrome also fails his test. Thanks!