Open
Bug 1127377
Opened 10 years ago
Updated 2 years ago
BrowserElementChild.js and friends may attempt to be loaded in a JS context (and fail) with version JSVERSION_DEFAULT due to CompilerOptions favoring currentScript()'s version over the global compartment's.
Categories
(Core :: DOM: Core & HTML, defect, P5)
Tracking
()
NEW
People
(Reporter: asuth, Unassigned)
Details
I am seeing this error while developing a (horrible) mochitest:
JavaScript strict error: chrome://global/content/BrowserElementChild.js, line 7: SyntaxError: let is a reserved identifier
The smoking gun is that in nsFrameScriptExecutor::TryCacheLoadAndCompileScript, the JS::CompileOptions has version = JSVERSION_DEFAULT, which causes TokenStream::checkForKeyword to freak out because "let" is a JSVERSION_1_7 token.
I traced this down.
Good news: nsFrameScriptExecutor::InitTabChildGlobalInternal explicitly does setVersion(JSVERSION_LATEST) on its option that it passes to InitClassesWithNewWrappedGlobal and so the compartment appropriately gets the correct version.
Bad news: nsFrameScriptExecutor::TryCacheLoadAndCompileScript initializes its options using:
JS::CompileOptions options(cx);
which ends up with the 2-arg constructor signature:
explicit CompileOptions(JSContext *cx, JSVersion version = JSVERSION_UNKNOWN);
which then does:
this->version = (version != JSVERSION_UNKNOWN) ? version : cx->findVersion();
and findVersion does:
if (JSScript *script = currentScript(nullptr, ALLOW_CROSS_COMPARTMENT))
return script->getVersion();
In my case, currentScript turns out to be a function in my mochitest code that's doing the appendChild of a mozbrowser iframe. gdb says that the script has a version of 0 (which is JSVERSION_DEFAULT). Interestingly, I explicitly loaded the entire JS file with an explicit content-type flagging it JS 1.7. Perhaps I need to prove that I love JS 1.7 by using a "let" somewhere in the file or function? (I'm going to attempt a workaround doing this soon.)
In any event, it returns JSVERSION_DEFAULT and that results in BrowserElementChild.js and everyone trying to be executed with the wrong version. And that breaks the cool beans mozbrowser APIs, I think.
My naive and lazy suggestion is that in TryCacheLoadAndCompileScript we change:
JS::CompileOptions options(cx)
to be:
JS::CompileOptions options(cx, JSVERSION_LATEST)
Based on googling for the error message, this seems somewhat rare, and likely to only be happening to some mochitests.
Reporter | ||
Comment 1•10 years ago
|
||
(In reply to Andrew Sutherland [:asuth] from comment #0)
> Interestingly, I
> explicitly loaded the entire JS file with an explicit content-type flagging
> it JS 1.7. Perhaps I need to prove that I love JS 1.7 by using a "let"
> somewhere in the file or function? (I'm going to attempt a workaround doing
> this soon.)
Unsurprisingly, the problem here was silly; the script tag had two "type" attributes, the first of which lacked the version parameter. I'm assuming a copy-and-paste snafu on my part somewhere along the line. Note that I don't think this moots the bug itself.
Comment 2•6 years ago
|
||
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046
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
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•