Errors thrown from message manager callbacks don't trigger window.onerror

RESOLVED FIXED in mozilla35

Status

()

RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: bholley, Assigned: bholley)

Tracking

unspecified
mozilla35
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Assignee)

Description

4 years ago
While hacking on test_cpows.xul, I noticed that I could introduce silly syntax all over the place and the test would still pass. As it turns out, this is a property of all message handlers in gecko right now. Yuck.

It looks like I probably broke this in mozilla25 with https://hg.mozilla.org/mozilla-central/rev/329b420eb34b

Thankfully, due to the recent JSAPI refactoring, we're now in a much better place to fix this than we were, and I wrote up a patch with tests. Let's see how many uncaught errors have accumulated in the meantime.
(Assignee)

Comment 2

4 years ago
Created attachment 8488952 [details] [diff] [review]
Part 1 - Handle null/undefined alternativeURI.host. v1

Without this, we fail in [1] and friends when we pass the host value to
asyncResolve.

[1] browser/base/content/test/general/browser_keywordSearch.js
Attachment #8488952 - Flags: review?(gijskruitbosch+bugs)
(Assignee)

Comment 3

4 years ago
Created attachment 8488953 [details] [diff] [review]
Part 2 - Use an AutoEntryScript in nsFrameMessageManager::ReceiveMessage. v1
Attachment #8488953 - Flags: review?(bugs)
(Assignee)

Comment 5

4 years ago
(In reply to Bobby Holley (:bholley) from comment #4)
> https://tbpl.mozilla.org/?tree=Try&rev=0bcef7823d07

Full try push is green.

Comment 6

4 years ago
Comment on attachment 8488952 [details] [diff] [review]
Part 1 - Handle null/undefined alternativeURI.host. v1

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

Ugh. I didn't even think that this was possible for http URIs! :-\
Attachment #8488952 - Flags: review?(gijskruitbosch+bugs) → review+

Updated

4 years ago
Attachment #8488953 - Flags: review?(bugs) → review+

Comment 8

4 years ago
Comment on attachment 8488953 [details] [diff] [review]
Part 2 - Use an AutoEntryScript in nsFrameMessageManager::ReceiveMessage. v1

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

::: content/base/src/nsFrameMessageManager.cpp
@@ +962,5 @@
> +
> +      // Note - The ergonomics here will get a lot better with bug 971673:
> +      //
> +      // AutoEntryScript aes;
> +      // if (!aes.Init(wrappedJS->GetJSObject())) {

Won't we need an nsIGlobalObject for the Init?
(Assignee)

Comment 9

4 years ago
(In reply to Bob Owen (:bobowen) from comment #8)
> Won't we need an nsIGlobalObject for the Init?

I think we should add a helper Init that does that step automatically. I thought it was part of jimb's patch, but maybe not.

Comment 10

4 years ago
(In reply to Bobby Holley (:bholley) from comment #9)
> (In reply to Bob Owen (:bobowen) from comment #8)
> > Won't we need an nsIGlobalObject for the Init?
> 
> I think we should add a helper Init that does that step automatically. I
> thought it was part of jimb's patch, but maybe not.

Ah, OK, it certainly makes things look tidier.
I think there were a couple cases where it would have been useful for AutoJSAPI as well.
https://hg.mozilla.org/mozilla-central/rev/753780842a33
https://hg.mozilla.org/mozilla-central/rev/f1572f664019
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
You need to log in before you can comment on or make changes to this bug.