Put Error.prototype on the proto chain of DOMExceptions

RESOLVED FIXED in mozilla32

Status

()

defect
RESOLVED FIXED
5 years ago
a month ago

People

(Reporter: bzbarsky, Assigned: bzbarsky)

Tracking

({dev-doc-needed})

unspecified
mozilla32
x86
macOS
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments)

This will just make instanceof work, but it's a start.  Hopefully no one will expect .stack to magically work as a result.

Note that this is a much more limited fix than bug 960508 and preserves all our Xray goodness.
Comment on attachment 8407681 [details] [diff] [review]
part 1.  Add JS_GetErrorPrototype to JSAPI.

You don't need this. Just call JS_GetClassPrototype(cx, JSProto_Error, ...).
Attachment #8407681 - Flags: review?(jorendorff) → review-
As far as I can tell, this changes our typical DOMException stringification from:

  [Exception... "An invalid or illegal string was specified"  code: "12" nsresult: "0x8053000c (SyntaxError) "  location: ""]

to:

  SyntaxError: An invalid or illegal string was specified
Attachment #8407693 - Flags: review?(peterv)
Comment on attachment 8407681 [details] [diff] [review]
part 1.  Add JS_GetErrorPrototype to JSAPI.

That would require a bunch of convolutions in the codegen.  I can do that if needed, but this seems much cleaner as API anyway (note that we already have it for Function, Array, and Object).
Attachment #8407681 - Flags: review- → review?(jorendorff)
Comment on attachment 8407681 [details] [diff] [review]
part 1.  Add JS_GetErrorPrototype to JSAPI.

Review of attachment 8407681 [details] [diff] [review]:
-----------------------------------------------------------------

OK.
Attachment #8407681 - Flags: review?(jorendorff) → review+
Attachment #8407682 - Flags: review?(peterv) → review+
Attachment #8407683 - Flags: review?(peterv) → review+
Peter, any chance of reviewing that last bit?
Flags: needinfo?(peterv)
Whiteboard: [need review]
Comment on attachment 8407693 [details] [diff] [review]
part 4.  Drop the custom stringifier from DOMException in favor of the default one on Error.prototype.

Review of attachment 8407693 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/webidl/DOMException.webidl
@@ +18,5 @@
>  [NoInterfaceObject]
>  interface ExceptionMembers
>  {
> +  // A custom message set by the thrower.  LenientThis so it can be
> +  // gotten on the prototype.

As discussed, please make a note that this is mainly for stringifying DOMException.prototype.

@@ +24,5 @@
>    readonly attribute DOMString               message;
>    // The nsresult associated with this exception.
>    readonly attribute unsigned long           result;
> +  // The name of the error code (ie, a string repr of |result|).
> +  // LenientThis so it can be gotten on the prototype.

And here.
Attachment #8407693 - Flags: review?(peterv) → review+
Flags: needinfo?(peterv)
Yeah, so there were three failures, all from this patch.

dom/imptests/html/dom/test_interfaces.html (M2) is an unexpected pass; easy to fix by removing the known-fail annotation.

dom/tests/mochitest/bugs/test_onerror_message.html (M3) is due to Error.prototype now being on the DOMException proto chain.  This causes IsDuckTypedErrorObject to find a property named "fileName" on the object, which means it never looks for "filename" and we lose the filename.  Jason, how would you feel about reversing the order of those two checks?  My other option is to list both properties on DOMException, both returning the same thing...

browser/devtools/webconsole/test/browser_webconsole_output_04.js (dt/dt3) is due to the devtools code doing String(exception) where "exception" is an Xray for a DOMException.  This used to call its toString, but now just returns "[XrayWrapper [object DOMException]" or something, since it doesn't see the content-side toString from Error.prototype.  Bobby, any sane ways of dealing with that short of leaving the toString on the interface (possibly [ChromeOnly])?
Flags: needinfo?(jorendorff)
Flags: needinfo?(bzbarsky)
Flags: needinfo?(bobbyholley)
Whiteboard: [need review] → [need info]
(In reply to Boris Zbarsky [:bz] from comment #11)
> browser/devtools/webconsole/test/browser_webconsole_output_04.js (dt/dt3) is
> due to the devtools code doing String(exception) where "exception" is an
> Xray for a DOMException.  This used to call its toString, but now just
> returns "[XrayWrapper [object DOMException]" or something, since it doesn't
> see the content-side toString from Error.prototype.  Bobby, any sane ways of
> dealing with that short of leaving the toString on the interface (possibly
> [ChromeOnly])?

Can we just fix the test?
Flags: needinfo?(bobbyholley)
It's not just the test.  You get the same behavior difference if you just open the devtools console and type print(foo) where foo is an exception object that was thrown by content.
Flags: needinfo?(bobbyholley)
(In reply to Boris Zbarsky [:bz] from comment #13)
> It's not just the test.  You get the same behavior difference if you just
> open the devtools console and type print(foo) where foo is an exception
> object that was thrown by content.

Yeah, but is that a problem? I mean, print(document) returns [object XrayWrapper [object HTMLDocument]].
Flags: needinfo?(bobbyholley)
That's a good point.  Seems to me like print() is pretty fundamentally busted?  We shouldn't exposing the XrayWrapper bits to web developers...
Flags: needinfo?(mihai.sucan)
Flags: needinfo?(jimb)
Attachment #8418058 - Flags: review?(jorendorff) → review+
Attachment #8418065 - Flags: review?(rcampbell) → review+
Assuming this doesn't actually needinfo from me anymore.
Flags: needinfo?(jorendorff)
Adding dev-doc-needed because, if I understand well, this change a bit the behavior of DOMException.
Keywords: dev-doc-needed
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.