NEW 204465
`unhandledrejection` event is fired later than specified 
https://bugs.webkit.org/show_bug.cgi?id=204465
Summary `unhandledrejection` event is fired later than specified
mike
Reported 2019-11-21 12:04:31 PST
## 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
Comment 1 2019-11-22 15:40:48 PST
<rdar://problem/57443584>
Ryosuke Niwa
Comment 2 2019-11-22 15:46:48 PST
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
Comment 3 2019-11-22 16:17:19 PST
> 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
Note You need to log in before you can comment on or make changes to this bug.