1617657 - Incorrect link in console for "TypeError: x called on an object that does not implement interface y"

Status: RESOLVED FIXED

(DevTools :: Console, defect, P3)

Description

[airhogs777]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0

Steps to reproduce:

1. Run the following in the console: DOMTokenList.prototype.contains.call(['hello'], 'hello')

Actual results:

Got the correct error "TypeError: 'contains' called on an object that does not implement interface DOMTokenList." but the [Learn More] link directed me to the page for "TypeError: "x" is read-only" https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Read-only

Expected results:

The [Learn More] link should direct to a relevant page. I'm not seeing one in the MDN "List of Errors" page (except maybe "TypeError: X.prototype.y called on incompatible type" ??)

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[:Harald Kirschner :digitarald]

Nicolas, I assume next step here is filing a bug to document MSG_METHOD_THIS_DOES_NOT_IMPLEMENT_INTERFACE. What's needed from the DOM/DevTools side?

Comment 3

[Nicolas Chevobbe [:nchevobbe]]

So this message is printed because errorMessageName is JSMSG_READ_ONLY which matches https://searchfox.org/mozilla-central/rev/49ed791eec93335abfe6c2880f84c324e73e47e6/devtools/server/actors/errordocs.js#18

What should be done is find which one of the C++ call using JSMSG_READ_ONLY should use something else instead (https://searchfox.org/mozilla-central/search?q=JSMSG_READ_ONLY&case=true&regexp=false&path=)

Comment 4

[Boris Zbarsky [:bzbarsky]]

The error message identifier here is MSG_METHOD_THIS_DOES_NOT_IMPLEMENT_INTERFACE, not JSMSG_READ_ONLY. But those two enum values (from different enums, note!) happen to have the same numeric value. The numeric value of the message is only meaningful if you know which callback function is used to produce the message string, and there are different callback functions for SpiderMonkey and the DOM. That is, the numeric message identifier on its own is not enough to identify the message involved, and devtools should really not be using it for that...

ccing some SpiderMonkey people who have expressed interest in generally making this stuff saner.

Comment 5

[Tom S. (please needinfo tschuster)]

What I suspect is happening that when we assign mErrorMsgName in xpc::ErrorReport::init, we always use js::GetErrorMessage to map the error number to the message. But like bz already hinted at, error numbers can be shared with other i.e. mozilla::dom::GetErrorMessage.

I don't think we can actually differentiate between these two at that point.

Comment 6

[Boris Zbarsky [:bzbarsky]]

That's correct...

I suppose one thing we could do in the DOM is add whatever the last JS error value is at the point where we call ReportErrorNumberWhatever and then subtract that off in our dom::GetErrorMessage to index into our array? Are there any other message-getters other than js::GetErrorMessage and dom::GetErrorMessage? Is the "last JS error value" available via jsapi?

Comment 7

[Tom S. (please needinfo tschuster)]

I think we should just change JSErrorReport to include the ErrorMsgName and set that in ExpandErrorArgumentsHelper or so.

Comment 8

[Tom S. (please needinfo tschuster)]

Attachment: Bug 1617657 - Store errorMessageName in JSErrorReport. r?jorendorff!,mccr8!

No test run yet, but manual testing shows the bug is fixed.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Nice! We should then add the DOM names to the stuff console knows about...

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4512dab2fe53
Store errorMessageName in JSErrorReport. r=jorendorff,mccr8

Comment 11

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/4512dab2fe53