Implement notifying of rejected promises (PromiseRejectionEvent)

RESOLVED FIXED in Firefox 68



2 years ago
17 days ago


(Reporter: ben.tian, Assigned: edgar)



Dependency tree / graph

Firefox Tracking Flags

(firefox68 fixed)




(2 attachments, 1 obsolete attachment)

This bug is to
1) implement notifying of rejected promises per HTML spec [1] and fire PromiseRejectionEvent [2], and
2) enable PromiseRejectionEvent interface implemented in bug 1338059.

Note bug 1338059 implements PromiseRejectionEvent interface but disables it until we actually fire the events.

[1] Section Unhandled promise rejections
Ben, are you planning to continue working on this?
Priority: -- → P2
Sure. Take this bug.
Assignee: nobody → btian
Added DDN keyword for tracking for doc purposes. Also added "PromiseRejectionEvent" to the summary to help make this bug easier to find using a quick search.
Keywords: dev-doc-needed
Summary: Implement notifying of rejected promises → Implement notifying of rejected promises (PromiseRejectionEvent)
ni? :overholt to prioritize this given the new information we have on usage.
Flags: needinfo?(overholt)
On our list :)
Flags: needinfo?(overholt)
Assignee: ben.tian → nobody
Note that this could cause bogus successes in tests, given testharness.js (by default) is meant to fail if there's unhandled rejections.
unhandledrejection lands in Servo at
Assignee: nobody → echen
Attachment #9040755 - Attachment is obsolete: true

(In reply to Edgar Chen [:edgar] from comment #10)

Created attachment 9040755 [details]
Bug 1362272 - Part 3: Enable on nightly and update tests;

I am going to do this in a separated bug.

Component: DOM → DOM: Core & HTML
Pushed by
Part 1: Add onrejectionhandled and onunhandledrejection EventHandler; r=smaug
Part 2: Implement notifying of rejected promises; r=smaug
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Created web-platform-tests PR for changes under testing/web-platform/tests
Upstream PR merged

This was already mostly documented, but I've polished things up and done the rest of the remaining bits:

:sheppy and others, are you sure Firefox 68 is or will be correct and not 69?

Via and leading to the comparison:

(In reply to kai.hollberg from comment #18)

:sheppy and others, are you sure Firefox 68 is or will be correct and not 69?

Via and leading to the comparison:

The implementation landed in 68 in this bug. We enabled it from 69 in bug 1525554 instead.

You need to log in before you can comment on or make changes to this bug.