Closed Bug 927610 Opened 7 years ago Closed 1 year ago



(Core :: DOM: Core & HTML, defect, P5)




Tracking Status
firefox71 --- fixed


(Reporter: emk, Assigned: bzbarsky)


(Blocks 1 open bug)



(3 files)

This is confusing and sometimes misused (see bug 926890).
Depends on: 827823
Summary: Get rid of NS_ERROR_DOM_TYPE_ERR → Get rid of NS_ERROR_TYPE_ERR

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
We should fix this, imo.  It's causing us to have spec-compliance bugs because people get confused and use NS_ERROR_TYPE_ERR.  See bug 1472095.

We need to kill NS_ERROR_DOM_TYPE_ERR too...
Assignee: nobody → bzbarsky
Depends on: 1308437
Depends on: 1472095
No longer depends on: 1308437
Component: DOM → DOM: Core & HTML

I filed bug 1581172 on NS_ERROR_DOM_TYPE_ERR.

Depends on: 1581278
Blocks: dom-error
Depends on: 1582196

The only ways DispatchReceivedData can fail are if our scope is torn down, we
OOM when creating a typed array, or we fail to queue a runnable. These all
seem like pretty unexpected situations, so NS_ERROR_UNEXPECTED seems
appropriate if we don't want to just propagate through the error from

The actual return code we return here doesn't really matter, since there is
already an exception on the JSContext. NS_ERROR_UNEXPECTED is as good as
anything, since we don't expect bogus options.

NS_ERROR_DOM_TYPE_ERR is not much better, but this at least allows us to get
rid of NS_ERROR_TYPE_ERR completely...

Attachment #9093952 - Attachment description: Bug 927610 part 3. Stop using NS_ERROR_TYPE_ERR in worker code. r=smaug → Bug 927610 part 3. Stop using NS_ERROR_TYPE_ERR in serviceworker code. r=smaug
Pushed by
part 1.  Stop using NS_ERROR_TYPE_ERR in UDPSocket.  r=smaug
part 2.  Stop using NS_ERROR_TYPE_ERR in windowutils.  r=smaug
part 3.  Stop using NS_ERROR_TYPE_ERR in serviceworker code.  r=smaug
You need to log in before you can comment on or make changes to this bug.