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)

x86_64
Linux
defect

Tracking

()

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.
(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.
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
Component: DOM → DOM: Core & HTML
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.