Closed
Bug 986459
Opened 10 years ago
Closed 8 years ago
Add the error object to worker's onerror
Categories
(Core :: DOM: Workers, defect)
Tracking
()
RESOLVED
FIXED
mozilla51
Tracking | Status | |
---|---|---|
firefox51 | --- | fixed |
People
(Reporter: evilpie, Assigned: bzbarsky)
References
Details
Attachments
(3 files)
No description provided.
Reporter | ||
Updated•10 years ago
|
Summary: Add the error object to window.onerror → Add the error object to worker's onerror
Assignee | ||
Comment 1•8 years ago
|
||
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)
Reporter | ||
Comment 2•8 years ago
|
||
Yes, I think that was about worker.onerror including the Error object.
Flags: needinfo?(evilpies)
Assignee | ||
Comment 3•8 years ago
|
||
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
Closed: 8 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 4•8 years 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•8 years ago
|
||
Assignee | ||
Updated•8 years ago
|
Attachment #8775753 -
Attachment mime type: text/plain → text/html
Assignee | ||
Comment 6•8 years ago
|
||
Assignee | ||
Comment 7•8 years ago
|
||
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.
Assignee | ||
Comment 8•8 years ago
|
||
Attachment #8784687 -
Flags: review?(amarchesini)
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → bzbarsky
Status: REOPENED → ASSIGNED
Updated•8 years ago
|
Attachment #8784687 -
Flags: review?(amarchesini) → review+
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•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/ae506f25d5f1
Status: ASSIGNED → RESOLVED
Closed: 8 years ago → 8 years 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.
Description
•