Add the error object to worker's onerror

RESOLVED FIXED in Firefox 51

Status

()

Core
DOM: Workers
RESOLVED FIXED
3 years ago
10 months ago

People

(Reporter: evilpie, Assigned: bz)

Tracking

unspecified
mozilla51
x86_64
Linux
Points:
---

Firefox Tracking Flags

(firefox51 fixed)

Details

Attachments

(3 attachments)

Comment hidden (empty)
(Reporter)

Updated

3 years ago
Summary: Add the error object to window.onerror → Add the error object to worker's onerror
What is this bug about, exactly?  Which error object should be added to where?  Is this basically like bug 873070 or something else?

Note that the spec says:

    For dedicated workers, if the error is still not handled afterwards,
    the user agent must queue a task to fire a trusted event that uses 
    the ErrorEvent interface, with the name error, that doesn't bubble 
    and is cancelable, with its message, filename, lineno, colno, attributes
    initialised appropriately, and with the error attribute initialised to
    null, at the Worker object associated with the worker.

Are you asking for that "initialised to null" to be changed to something else?  If so, that seems like something you should raise as a spec issue.
Flags: needinfo?(evilpies)
See Also: → bug 873070
(Reporter)

Comment 2

11 months ago
Yes, I think that was about worker.onerror including the Error object.
Flags: needinfo?(evilpies)
OK, how should this work, given that they're different JSRuntimes/threads?  If you do have ideas, please propose them as spec issues.
Status: NEW → RESOLVED
Last Resolved: 11 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 873070
(Reporter)

Comment 4

11 months ago
Okay, thinking about this a bit more and reading bug 355430 again: This was actually about onerror in the Worker scope. It seems like the error object parameter there is always null.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Reporter)

Comment 5

11 months ago
Created attachment 8775753 [details]
test
Attachment #8775753 - Attachment mime type: text/plain → text/html
Created attachment 8784505 [details]
Testcase not using the non-standard Array.map thing
Thanks, that's pretty clear.  The spec does say that inside the worker the .error on the error event should be the right thing.

It looks like Chrome gets this wrong too; I've filed <https://bugs.chromium.org/p/chromium/issues/detail?id=640724>.  WebKit nightly gets it right.
Created attachment 8784687 [details] [diff] [review]
The error event in a worker (firing at the worker's global) should have the original exception value in its .error property
Attachment #8784687 - Flags: review?(amarchesini)
Assignee: nobody → bzbarsky
Status: REOPENED → ASSIGNED

Updated

10 months ago
Attachment #8784687 - Flags: review?(amarchesini) → review+

Comment 9

10 months ago
Pushed by bzbarsky@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/ae506f25d5f1
The error event in a worker (firing at the worker's global) should have the original exception value in its .error property.  r=baku

Comment 10

10 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/ae506f25d5f1
Status: ASSIGNED → RESOLVED
Last Resolved: 11 months ago10 months ago
status-firefox51: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
You need to log in before you can comment on or make changes to this bug.