Closed
Bug 960246
Opened 11 years ago
Closed 11 years ago
Message manager loadFrameScript doesn't handle failure correctly
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
FIXED
mozilla29
People
(Reporter: billm, Assigned: billm)
References
Details
Attachments
(3 files)
(deleted),
patch
|
bholley
:
review+
smaug
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
smaug
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
smaug
:
review+
|
Details | Diff | Splinter Review |
When the message manager calls JS_ExecuteScript for content scripts, it ignores errors. However, there's a problem if there was already JS on the stack when LoadFrameScriptInternal was called. In that case, the JS engine will leave an exception on the JSContext, which is just an AutoSafeJSContext. Whoever is unlucky enough to get that context next will randomly encounter that exception and fail. This patch just reports the error, which I think is good practice anyway.
If you're wondering how there can be JS on the stack when LoadFrameScriptInternal is called, it happens when we're running in single-process mode. In that case, calling messageManager.loadFrameScript in JS will just run the script directly.
Attachment #8360622 -
Flags: review?(bugs)
Attachment #8360622 -
Flags: review?(bobbyholley+bmo)
Comment 1•11 years ago
|
||
Comment on attachment 8360622 [details] [diff] [review]
message-manager-error-fix
Review of attachment 8360622 [details] [diff] [review]:
-----------------------------------------------------------------
Ugh yeah.
In theory, AutoSafeJSContext unconditionally pushes a JSContext, which one would think would insert a SavedFrameChain boundary, which should cause SpiderMonkey to invoke js_ReportUncaughtException at the end of the JS_CallFunctionValue call. However, there's this stupid optimization where we don't invoke JS_SaveFrameChain if the push wouldn't change the principal. So if the caller is also using an AutoSafeJSContet, they get screwed.
This needs fixing in the long run, but this is fine for now. r=bholley
Attachment #8360622 -
Flags: review?(bobbyholley+bmo) → review+
Updated•11 years ago
|
Attachment #8360622 -
Flags: review?(bugs) → review+
Assignee | ||
Comment 2•11 years ago
|
||
I started poking around in this code some more, and I couldn't stop myself from making this change. I haven't seen any other code that uses |ctx| instead of |cx| for a JSContext.
Attachment #8360823 -
Flags: review?(bugs)
Assignee | ||
Comment 3•11 years ago
|
||
After some more debugging, I found that this was causing my second test failure (specifically the JS_CallFunctionValue, although it's easy to see how the JS_Stringify could fail too).
Attachment #8360825 -
Flags: review?(bugs)
Updated•11 years ago
|
Attachment #8360823 -
Flags: review?(bugs) → review+
Updated•11 years ago
|
Attachment #8360825 -
Flags: review?(bugs) → review+
Assignee | ||
Comment 4•11 years ago
|
||
I pushed these to fx-team since my session restore changes rely on them and the chance of a merge conflict seems very low.
https://hg.mozilla.org/integration/fx-team/rev/d020e9d743a6
https://hg.mozilla.org/integration/fx-team/rev/3dcedecd2bbf
https://hg.mozilla.org/integration/fx-team/rev/2e1513b84c6c
https://hg.mozilla.org/mozilla-central/rev/d020e9d743a6
https://hg.mozilla.org/mozilla-central/rev/3dcedecd2bbf
https://hg.mozilla.org/mozilla-central/rev/2e1513b84c6c
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•