al_9x wrote:
first a few general question about JS versioning, because there's a problem, it's not clear how it's supposed to work:
What is the default version? Is it latest supported minus certain Mozilla extensions requiring explicit version?
It's the latest version including all the Mozilla-specific extensions for chrome components and modules, and the latest version minus
syntax incompatible with ECMAScript for content (i.e. new/extended host objects work, but new keywords / syntactic sugar like "let", "yield" or shorthanded functions don't).
In other words, if and only if you want to use "let" "yield" & C. in a XUL or HTML page, you need to specify a version equal or higher 1.7 (1.8 for braceless functions).
al_9x wrote:
Is there a way to say (latest supported including all Mozilla extensions), without specifying a number? That's probably what's desired.
None that I know.
al_9x wrote:What is the latest version, 1.8.5?
Yes it is, but apparently nothing higher than 1.8 seems to be accepted as an explicit version number, probably because that's the latest version with incompatible keywords/syntax.
al_9x wrote:Is the specified version intended to mean "disable all features from later versions" and "enable all Mozilla extension up to this version?"
Yes, AFAIK. The supposed rationale is preventing older scripts from breaking (e.g. by using "yield" as a function name).
al_9x wrote:If the current version is 1.8.5, does setting it to 1.8.1 disable both ECMAScript5 and Mozilla extension features from 1.8.5?
There's no Mozilla extension feature that I know about past 1.8.
Regarding ECMAScript 5 features, they all work since there's no syntax incompatibility.
now the problems:
al_9x wrote:surrogates are completely broken
This is due to using 1.8.1 rather than 1.8, something I already had fixed but was left out by accident from rc3 (I was sure it was there, but it wasn't). Fixed in
rc4
al_9x wrote:Why swallow surrogate errors in normal mode?
Because, since they run in a hostile/unaware environment by definition, some surrogates are expected to fail
at runtime sometimes, and you don't want to pollute the console (and have a performance hit too, from this) unless you're debugging.
al_9x wrote:What seems to be happening is that if the js engine fails to parse the entire concatenated blob (which is not just surrogates, but js injections backing NS core functionality), then all of it is lost.
Yes, it's expected because they're a single parse unit.
al_9x wrote:If so, at a minimum, NS code should be isolated from surrogates
It is.
al_9x wrote:
but even different surrogates interfering with each other is not a good thing.
You're not expected to keep surrogates with syntax errors in place. And if you're fiddling with your own surrogates, you're supposed to be a geek and able to clean up your mess, aren't you?
al_9x wrote:Is it too much of a perf hit to isolate them?
Yes it is. It means multiple sandboxes / script DOM elements to be inserted, instead of just one.
al_9x wrote:
Another (theoretical) possibility is to somehow parse them, detecting syntax errors without execution, excluding the bad ones. Does the engine offer such a service?
This is actually a good idea. The browse does offer a parse-only facility in very recent versions (actually I must check whether it's on trunk/betas or still in a separate experimental branch), but I've been doing this by hacking the old good Sandbox in InjectionChecker for years (I just run "new Function(scriptText)", to parse but not execute, and see if it sticks).
al_9x wrote:Obviously you would only want to do this exclusion parse once after modification, but that would not work for file based surrogates, whose modification can't be detected.
Of course. Putting this in my TODO list.
al_9x wrote:
One mystery does remain, why does the !@ follow @ in the concatenated blob? They are supposed to execute at different times. [/list]
They're in the same blob, but the !@ ones are wrapped inside
addEventListener("DOMContentLoaded", function() { ... }, false).
