SharedWorker.onerror gives Event instead of ErrorEvent on syntax error
Categories
(Core :: DOM: Workers, defect, P3)
Tracking
()
People
(Reporter: elkurin, Unassigned)
Details
(Whiteboard: dom-lws-bugdash-triage)
Attachments
(1 file)
451 bytes,
text/html
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36
Steps to reproduce:
Create SharedWorker with a syntax-error script (like '1 + ;') and catch error.
Actual results:
error.message is sometimes |undefined| and sometimes filled by running the same code.
This is because the type of error object is randomly chosen from |Event| type and |ErrorEvent| type.
Expected results:
The type of error must be fixed for the same situation.
According to the spec, it could take both |Event| type and |ErrorEvent| type (spec:https://html.spec.whatwg.org/multipage/indices.html#event-error), but |ErrorEvent| might be better since we can extract error.message.
Hi, Eriko Kurimoto!
Thanks for your contribution!
I don't have the technical knowledge to reproduce this issue, but I will add product and component to keep on track. If you have any other details or info feel free to add it on a thread here.
Please let us know if this issue is reproduced in the latest Nightly edition. You can download it from here: https://nightly.mozilla.org/
If you still have the issue please create a new profile, you have the steps here: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager
support.mozilla.orgsupport.mozilla.org
Once you have all this information, please let us know so we can continue investigating.
Regards,
Reporter | ||
Comment 2•6 years ago
|
||
Hi.
I could reproduce this error in the latest Nightly edition by using the test attached in the previous report above.
You can reproduce it by adding onerror.html(attached file) and syntax-error.js(explained in the comments inside the attached file 'onerror.html') as web-platform-test, and run onerror.html test several times. Then you can see the failure text. This failure text is one of the following texts:
- FAIL hoge promise_test: Unhandled rejection with value: object "[object ErrorEvent]"
- FAIL hoge promise_test: Unhandled rejection with value: object "[object Event]"
By running this test several times, you can see both of the failure texts. Failure itself is correct but failing with different comments is not correct. and shouldn't happen. This test implies that EventType of onerror is randomly chosen from ErrorEvent or Event.
This is the information about the bug. I hope this would help you!
Also, I couldn't quite understand about creating a new profile. Is it helpful for your investigation?
Updated•6 years ago
|
Updated•6 years ago
|
Updated•5 years ago
|
Comment 3•1 year ago
|
||
The test case now always gives Event from error event on my machine, while Chrome silently fails without error event. But then if I change SharedWorker to Worker then Chrome gives ErrorEvent while Firefox still gives Event.
The spec doesn't seem to say about throwing error per https://html.spec.whatwg.org/multipage/workers.html#run-a-worker and https://html.spec.whatwg.org/multipage/webappapis.html#run-a-classic-script through step 10. Andrew, can you double check?
Comment 4•1 year ago
|
||
I see that https://github.com/whatwg/html/issues/5323 that had a lot of relevant context is still open, although a bunch of things landed.
Description
•