Enable userscripts (*.user.js) to access newer JavaScript engine syntax

[Martii]

Original Ticket: DevjaVu ticket 32
Original Title: Javascript 1.7?
Original Type: Defect, Major priority
Original Report: Approximately 2 years ago.
Original Text:

How do you get JavaScript? 1.7+ enhancements enabled in GM? Dev List Discussion

New Type: Enhancement, Normal priority

 Allow user scripts to access newer JavaScript engine syntax in 3.5.X+, such as block scope let for better, faster and more secure OOP.

 When evalInSandbox is passed this parameter in an older Firefox, it will be ignored and default back to baseline JavaScript engine support.

Single line modification at #L330 from Components.utils.evalInSandbox(code, sandbox); to Components.utils.evalInSandbox(code, sandbox, "1.8"); will allow this.

Sample:

for (let i = 1; i <= 3; ++i) {
  GM_log('looping ' + i + ' times');
}

GM_log(i);  // This will produce i is not defined since i is block scoped

Reference:
MDC evalInSandbox

MDC JavaScript Engine Version Syntax

It would be nice to see this one line fix in 0.8.2, but it's understandable that it may not make it until next time.

See also:
Martii commit

johan commit

johan commit

johan commit

arantius commit

greasemonkey commit

[ocornu]

This new evalInSandbox syntax is FF3.5+ only...

[Martii]

BlindWanderer wrote:

You (Oliver) missed the boat on this one;...

ocornu wrote:

This new evalInSandbox syntax is FF3.5+ only...

That is what is precisely stated in this Issue. I will repeat, paraphrased, for those still not comprehending... Regression tests all pass as the parameter is ignored.

[ocornu]

Still: GM scripts using JS-1.8 features will install just fine on FF<3.5 and... crash.
Thus this one-liner is not addressing the problem, imo.

The original ticket proposed an explicit @jsversion header tag: among other things, it allows GM to forbid installing scripts depending on features not available in the host browser.
That's why a @jsversion tag is planned for Webmonkey even though WM is FF3.5+ only.

[Martii]

ocornu wrote:

GM scripts using JS-1.8 features will install just fine on FF<3.5 and... crash (the user.js and not Greasemonkey).

I thought you might try to pull that rabbit out of your hat... but while you were out, the userscript community as well as userscripts.org already has several ideas planned (and some authors have implementations in alpha/beta/golden already)

I initially didn't understand these users request until a few came by and pointed out the missing the boat bit. You are still missing the boat unfortunately. :(

It is quite easy to detect the browser version and warn accordingly from the source script site... it's just a matter if the Code Monkeys want to have it bad enough and want to get out from swingin' in the trees long enough to further it.

It is a terrible concept to limit Firefox user scripting to just JavaScript 1.6 while all the other browsers aren't limiting themselves.

Sure more metadata block keys would be interesting, but those are a luxury... the built in methods I've seen, and developed a few myself, are far superior to extra keys. The metadata block is quite simplistic in it's concept and should probably remain small otherwise it could easily get bigger than some scripts. (see @match with regular expressions capability discussions)

I prefer to run on the same quote as Anthony has stated:

The more esoteric the method, the less likely that it has been included in the Greasemonkey sandbox.

Developing another key handler is far more complicated and slower than using what Mozilla has already done in the binary and extra keys will open up doors for less compatibility with the Greasemonkey extension.

[erikvold]

Hey Martii,

Just add the "1.8" param is my opinion, because it is simply changing the default from 1.6 to 1.8 for FF3, and @jsversion can still be added later if desired.

The only advantage to @jsversion is that we could prevent 1.8 scripts from running on ff2, but like I say that can be added later.

[Martii]

erikvoid wrote:

...can still be added later if desired...

Agreed. It makes more sense to go incrementally and there are always bigger alternatives to detecting JavaScript versions... some are in use already. :)

[ocornu]

I'm not sure what alternatives you are talking about...

The whole point of conditioning JS>1.6 support to a new @jsversion tag is to avoid widespread implicit usage in the wild of features that will "silently" break on older JS engines.
There is no point in adding @jsversion later: if it was optional it wouldn't fix the problem, if it was required it would break those scripts relying on implicitness. Either we condition JS>1.6 support to a @jsversion tag from the start or we forget about @jsversion completely.
Introducing a new breed of bugs that cannot be cleanly fixed afterwards can hardly be called "going incrementally". :-)

Knowing how impetuous you may be, let me say that i don't mind what solution is elected eventually (as written above, WM is FF3.5+ only anyway).

[erikvold]

I think you're letting perfect be the enemy of good.

"There is no point in adding @jsversion later: if it was optional it wouldn't fix the problem, if it was required it would break those scripts relying on implicitness."

It would "not break those scripts relying on implicitness.", because they would already be broken if we simply add the "1.8" param, and they are broken as we speak. However it does fix those userscripts that wish to use 1.8 for ff versions that support it.

Greasemonkey only supports <=1.6 at the moment, and anything > 1.6 is broken for all versions of firefox. Only versions >= FF 3.0 support 1.8 and the extra param. Therefore adding the param changes nothing for versions < FF 3.0, and allows Greasemonkey to support js versions <= 1.8 for versions of FF >= 3.0.

I think your hang up is that userscript authors will start writing 1.8 userscripts that will not work on older versions of FF and have no way of knowing, and end up with errors, causing bug reports to creep up. But I think userscript authors will try to let users know of this first of all, and second of all adding @jsversion would fix the problem if userscript authors update the script and users get the update. That's not such a bad downside when compared to the upside.

[ocornu]

It would "not break those scripts relying on implicitness.", because they would already be broken if we simply add the "1.8" param

Sorry, i'm afraid i don't get that.

I think your hang up is that userscript authors will start writing 1.8 userscripts that will not work on older versions of FF and have no way of knowing, and end up with errors, causing bug reports to creep up.

That's right. Why let this happen when we can easily avoid it?

But I think userscript authors will try to let users know of this

Isn't it precisely what @jsversion explicitly achieves?

adding @jsversion would fix the problem if userscript authors update the script and users get the update. That's not such a bad downside when compared to the upside.

Well, you know what they say: in a perfect world... ;-)
I'm not sure what the upside of not having @jsversion is, though.

[erikvold]

You should try to get my point, I think you would understand why the pain isn't so bad if you did.

Why let this happen if we can avoid it? because it is practically speaking a non issue.

Isn't it precisely what @jsversion explicitly achieves? Yes you understand it correctly.

"I'm not sure what the upside of not having @jsversion is, though." Me too, and if you have it in your clone I'll gladly pull it, until then this incremental change is a good one in my opinion.

[ocornu]

Why let this happen if we can avoid it? because it is practically speaking a non issue.

Ok, i guess this is where we disagree then: i'm not trying to dramatize the issue but my opinion is that it is worth dealing with, especially as it can be dealt with rather easily. This being said, i'm not sure i correctly got your point -- although i've tried.
If the GM team agrees on @jsversion (or whatever it ends up being called -- i personally like the simpler @js which is further away from the widespread @version), i'm sure Marti can come up with a patch shortly, if he wants to.

I don't have a GM clone per se: WM is quite far from the GM code now.
The WM patch would be pretty simple as there is no backward compatibility issue (no "your browser cannot run this script" dialog/locales) and WM already uses the new evalInSandbox syntax:

• parse the new @tag (one-liner)
• save it to config.xml (one-liner)
• load it back from config.xml (one-liner)
• use it at injection time (one-liner)

[erikvold]

@jsversion is more explicit though, I think that ought to be the tag..

[ocornu]

I understand (and expect some will share your opinion).

My opinion is that a statement like:
// ==UserScript==
// ...
// @js 1.8
... is univocal enough (and there is less chances to mistake it for another tag).
But that's just me.

[Martii]

ocornu wrote:
...conditioning...

Conditioning whom? I don't think you are giving the proper credit to some authors, contributors and scriptwrights.

ocornu wrote:
...avoid widespread implicit usage...

Other browsers are doing just fine with newer JavaScript syntax... you keep missing the point.

ocornu wrote:
Introducing a new breed of bugs that cannot be cleanly fixed afterwards...

So you are challenging both Mozilla and Brendan Eich?... interesting concept.

 

ocornu wrote:
...Knowing how impetuous you may be,...

_cough_ If you recall I turned you down when you asked me to leave Greasemonkey and assist in developing your own personal breed of addon. I prefer to work in a community... with a few hurdles to overcome in communication I think I've managed to find a bunch of good people... you prefer to go solo... but enough of your attempt to steer the ticket off track.

erikvold wrote:
...I think you're (Oliver) letting perfect be the enemy of good....

I would have to agree... Oliver appears to be making a mountain out of a mole hill.

erikvold wrote:
...I think userscript authors will try to let users know of this first of all....

Some already do including myself. Some even use JavaScript 1.8 syntax already.

ocornu wrote:
...Why let this happen when we can easily avoid it?...

First off the only bug reports would be Firefox to Greasemonkey incompatibility. This is what the dev group is all about. The issue stated here is a user issue. Userscripts.org, irc channel and the users group on google is perfectly capable of fielding questions and issues as far as user scripts go. Greasemonkeys concern should be with security and interopability with the browser itself. I concur with it being a non-issue.

ocornu wrote:
...i'm sure Marti can come up with a patch shortly, if he wants to....

I could "do it all"... but that's not my style and that's not very productive. I would prefer to get more community involvement in a NEW issue to hear pro vs con. So far you've overly dramatized it by blowing this simple enhancement into a major feature enhancement soley dependent upon GM. The fix proposed would allow more involvement from everyone to develop further capabilities, not just you and not just Greasemonkey.

I have never said that you can't do your suggested key. You just need to learn how to coop better and work incrementally... I've had my share of rough edges smoothed out as well, but you seem to be exactly the same as the last time we chatted.

[ocornu]

...Knowing how impetuous you may be,...

cough If you recall I turned you down when you asked me to leave Greasemonkey and assist in developing your own personal breed of addon...

Look, Marti, I don't want to be mean but i never asked you to leave GM: you had been dumped long ago. It is true i answered you and proposed you to jump on the WM train... you did not answer back. Fine with me. :-)
Yes, after two "border-line" posts i wrote that you could be impetuous. I'm sorry, but your last post just proves my point.

Now, can we get back to our business?
Can you explain clearly what is your technical problem with a JS version header tag? Why silently defaulting to JS-1.8 on some browser versions is the way to go?

[erikvold]

I only have a small issue with @js being slightly non user friendly in that it raises a thought bubble that could be avoided with @jsversion.

[Martii]

ocornu wrote:
...Yes, after two "border-line" posts i wrote that you could be impetuous...

Your underlying agression is unappreciated and you like to play with your words to manipulate others. You also seem to project your own feelings about yourself onto others and you use the term "we" a lot... who else are you speaking for? How about talking in the first person instead? As far as I can tell you have one maybe two interested parties in WM... show me if I'm wrong in your project and definitely don't waste the time of GM by doing it here.

As far as I'm concerned your credibility was lost a long time ago trying to usurp GM from Aaron, Johan and Anthony and the rest of the contributors. I have never stated that you are rash or emotional, yet you continually seem to demonstrate it in any communications... not just to me either. You changed the subject, not I and not anyone else.

 

ocornu wrote in an email to Martii:
For this very reason i take it as a personal victory that Anthony is leaving, this time, without being able to put everything on my shoulders.

This was your response to my suggestion that you should ease off on your aggressive responses or you could end up being similarly banned when Anthony went "dark". I'll let the community be the "judge" of things.

As far as your input is concerned, you are welcome to share your opinion with someone else, but you are definitely untrustworthy and I won't give you the power that you so desperately crave. I'm sorry Oliver, but your input will be ignored deprecated by me from now on because I don't have the time to deal with your petty attacks like you have demonstrated in this ticket.

erikvoid wrote:
...@js being slightly non user friendly...

I agree however this should be saved for a different issue (ticket) as the scope of that should be tackled after building the foundation. As we've seemed to agree, it's better to take small steps as a group rather than attempt to do it all at once and solo. I do value your input as you've kept my mind open skillfully. :) Thanks.

[tim-smart]

I have been briefly browsing this thread over the last day, and just to add:

• There isn't really a need for a extra tag. Problems that arise to this addition are browser specific, and not within the scope of Greasemonkey itself. Alerting the user that their browser is out of date is more of a hindrance than a positive thing. It is up to the developer to alert their users that their script is using 1.8, metadata isn't the place to do it.
• This is a very similar issue to cross-browser User Script support, at present if a User Script uses a GM_* API that another browser does not support, the only valid option to get a working script is to get the latest version of Firefox + Greasemonkey. In the same fashion if a script will make use of a 1.8 API, the users either get over it or get the latest Firefox installment. Problems WILL arise, problems ALWAYS arise, but an neglect-able amount will be because of this issue.
• Upgrading to 1.8 will not break previous scripts (obviously), so making the change does not have any immediate consequences. Stop kicking around the pool, and take a dive. The water is rather nice.

[erikvold]

I agree with you Tim, I do not see the need for the tag, any more than I see a need to signal that a GM_* api function is used. If there was a performance difference maybe I would care..

[erikvold]

Maybe we should add @gmversion too?

[ocornu]

Problems WILL arise, problems ALWAYS arise, but an neglect-able amount will be because of this issue.

I'm mentioning the compatibility issue and its tag solution because of earlier discussions on gm-dev explaining how important backward compatibility is for the GM team: breaking 0.04% of uso scripts (iirc) was then considered a no-go. The expected impact of this change on users, although low, is much bigger.

Upgrading to 1.8 will not break previous scripts (obviously)

I'm not so sure about that: how come evalInSandbox does not default to the latest JS version available, then? Why is the new feature only making newer versions an optional argument? The original mozilla ticket explicitly answers: to prevent production code from breaking.
As an example: var let = 0 works with 1.6 and breaks with 1.8.

Alerting the user that their browser is out of date is more of a hindrance than a positive thing. It is up to the developer to alert their users that their script is using 1.8, metadata isn't the place to do it.

It is not about warning users that their browser is out-of-date, it is about preventing scripts that will crash to get installed in the first place, which is a GM consistency issue.
Not all users know about javascript 1.8, or even what browser version they are running. You are assuming a computer-savvy user. I'm willing to make it work for grand-ma. :-)
Beside, not all scripts are published via a web page where the dev may (or may not) warn users about JS compatibility issues.
As it is nearly impossible to detect what JS version is used, it is better to simply mention it explicitly. And the metadata block is the right place for that, just like the <script> tag is (was) the right place in the content page.

[Martii]

@ocornu

You've been "upgraded" to deprecated as requested from a fellow Mozilla peer.

ocornu wrote:
...because of earlier discussions on gm-dev explaining how important backward compatibility is for the GM team: breaking 0.04% of uso scripts (iirc) was then considered a no-go. The expected impact of this change on users, although low, is much bigger....

While there may be other cases in the GM-dev group, you might recall that I am one of the proponets for maintaining Firefox 1.5 and Seamonkey compatibility. GM already made breaking changes when they eliminated Seamonkey direct support. Since you seem incapable of properly citing reference... here is a link to the original ticket discussion. This makes absolutely no reference to any of your claims... perhaps you should do the research before making your assumptions.

ocornu wrote:
...how come the Sandbox does not default to the latest JS version available, then?....

This is semi-valid question. Why does the JSON object work with no reference to 1.8 build 1? The primary Authors have repeatedly stated that the sandbox is not on their favorite list. Mozilla obviously has a few inconsistencies here and there... in the meantime should we all just sit back and play "grand-ma" and not contribute to open-source development?

ocornu wrote:
...The original mozilla ticket explicitly answers: to prevent production code from breaking.....

There you go again reaching into that magic hat of yours. I'm failing to see exactly where in the bugzilla report it says anything about this and it seems that you are mixing up what production code means. Greasemonkey is production code, user scripts typically are not.

ocornu wrote:
...var let = 0...

This makes about as much sense as var while = 0;. Authors, Contributors and Scriptwrights know better than to use reserved JavaScript identifiers and if they don't they usually get negative feedback from their users.

ocornu wrote:
...You are assuming a computer-savvy user...

You are assuming that everyone is computer illiterate. Some of my network doesn't have a clue how "my wizardy" works in some of my scripts and shared collaborations... Some can dance circles around me... but trust is initially given and continually earned by those that don't understand. Sometimes they do want to understand and some don't want to understand... this is a concept that I'm quite familiar with. Are you?!

ocornu wrote:
...Beside, not all scripts are published via a web page where the dev may (or may not) warn users about JS compatibility issues. Think about Greasefire installs for example....

Don't try to make up how Greasefire works... I'm sorry but you have no comprehension how Greasefire actually works. Greasefire is actually quite involved with the community at userscripts.org... so anything that Greasefire installs relies on userscripts.org and the Admin there is quite capable. Again you don't give Authors, Contributors and Scriptwrights their due credit.

ocornu wrote:
...the metadata block is the right place for that...

The metadata block key is another option to be considered in this issue (ticket).

I could go on with this evaluation and might, but it still stands that this simple fix will allow more development from the "grand-ma"'s using Firefox.

[ocornu]

Please, Marti, "ignored" was just fine with me: keep it this way. Please.
This is no place for... whatever your comments on me may be called. You can despise me all you want, you are free to cry it out loud in public, but let's keep this ticket focused on solving its issue, ok?

...how come the Sandbox does not default to the latest JS version available, then?....

This is semi-valid question... The primary Authors have repeatedly stated that the sandbox is not on their favorite list. Mozilla obviously has a few bugs here and there...

Frankly, i don't think this is a bug. If you are convinced of the opposite i suppose you should open a new Mozilla bug ticket.

The original mozilla ticket explicitly answers: to prevent production code from breaking.....

There you go again reaching into that magic hat of yours. I'm failing to see exactly where in the bugzilla report it says anything about this

The bug report description states:

I recommend that xpc_CreateSandboxObject() explicitly use JS_SetVersion() to set the JS version of new sandboxes to use whatever pre-1.7 JS version Firefox currently defaults to (since we don't want to break existing production code), and also allow for an optional version parameter to be passed in to Components.utils.Sandbox(), which overrides this default behavior.

[Martii]

ocornu wrote:
...Please, Marti, "ignored" was just fine with me: keep it this way. Please...

Not a chance after discussing this with my Mozilla peer... although he did give me a few pointers on dealing with what others have called "Poisonous Developers" such as yourself.

If it were my decision, I'd ask you to go return to your own isolated project and stop bothering Greasemonkey with your own ambitions for furthering your own fork of Greasemonkey (Web Monkey)... but it's not... so I wouldn't recommend that you tell people what to do either. Your choice of words are poor and you lack cooperational skills in any environment.

ocornu wrote:
...If you are...

I won't play your "what if" scenario. The facts are presented and down the line Aaron, Anthony and Johan will decide what is appropriate.

ocornu wrote:
...(since we don't want to break existing production code)...

Again you are misinterpretting this especially since this is one of the earlier on comments. Unfortunately on the first round of research, Ctrl-F didn't find this... which is curious but thank you for actually fully citing for once.

ocornu wrote:
...let's keep this ticket focused on solving its issue, ok?...

Hmmm I could have sworn that I stated multiple times to keep it focused before you derailed it with your condescending comments and changing the topic of this issue. As far as I'm concerned, this issue is complete... you may pollute your own talks at this issue.

[ocornu]

The facts are presented and down the line Aaron, Anthony and Johan will decide what is appropriate.

Exactly: i'm not the one who's going to decide this. Thus there is no reason to feel threatened and overreact just because i happen to disagree with you. :-)

[Martii]

ocornu wrote:
Exactly: i'm not the one who's going to decide this.

ocornu wrote in an email to Martii:
How i wish Aaron was the only admin to deal with.

cough Everyone will have issues at one point or another... and you are not excluded from it either. I'm not intimidated by you nor am I threatened. I do wish you would stop projecting. I think the appropriate phrases for my feelings is exhausted from your attacks and endless replies but there is always tomorrow... so don't get your hopes up on any kind of "victory".

As Anthony stated you have some good ideas, but as I stated you need to learn to work incrementally and in a community setting. There is still the looming alterior motives quoted from you earlier but I'm satisfied that others will make their own decisions regarding that.

I notified you of your mistake as a courtesy to prevent your voice from being extinguished... something I wasn't afforded on the Greasemonkey-dev group... and you successfully gained the primary Authors sympathy. What I got was a good lesson about what not to do and also who to watch out for (mainly the cave trolls that came out and assumed I have some sort of rare disease which I actually found out was a reference to an episode of Boston Legal EDIT: And most recently Johan's uncivil manner and continuing personal vendetta by claiming I have autism.)

ocornu wrote in an email to Martii:
i believe the current greasemonkey development ecosystem just cannot change, it doesn't even _want_ to.

This might have been a semi-truth, but considering back then when you first stated this, I was quite ignorant of the actual community. This is one of the many reasons I've stuck around and learned my lesson by actually becoming a part of the community.

ocornu wrote in an email to Martii:
i'll say a bit more of my intentions in this regard. GM is the core and provides basic functionalities: it's a package manager (it allows to install, uninstall scripts and resources) and it's a virtual machine (it builds a runtime script environment and injects them in pages). But from an average internet user standpoint it's mainly irrelevant.

_cough_ IMHO GM is the defacto standard... more people flock to GM than any other browsers support channels. If you paid attention to the stats you would know this. My corrected mistake is not giving proper credit to the GM authors back then... I'm a lot wiser to my mistake and your continued mistake.

ocornu wrote:
... because i happen to disagree with you. ...

You derailed the topic by trolling for you own attention and you never seem to stop. If you wish to continue this in a different public venue outside of Greasemonkey, I'm for it... but I made the mistake of being lured into your web back in February but luckily I finally understood my "red flag" about your intentions.

[johan]

Martii: Be civil; this is an issue tracker, not a forum for childish drama, name calling and righteousness contests. You were deemed poisonous and banned from GM-dev back in Aaron's days, and you're well advised not to get back on that track here. You will not get as many warnings as you got back then, if you stick to this tone here.

Kudos for picking up on our and raising to our attention that we missed the solution in GM:#32, though. I hacked it a bit to get rid of the "1.8" constant so we don't have to track Mozilla-trunk when that gets out of date in this changeset. Anthony: I'm okay with either that (+1) or the trivial recurring fix (+0), should you prefer that one.

Tagging for 0.8.2.

[Martii]

johan wrote:
You will not get as many warnings as you got back then.

I didn't get any warnings as quoted directly above by Aaron himself. But you are correct... I learned my lesson and hopefully you have come to appreciate my usefulness in my persistence. Have you? Has Oliver?

johan wrote:
Kudos for picking up on our and raising to our attention that we missed the solution in GM:#32, though. I hacked it a bit to get rid of the "1.8" constant so we don't have to track Mozilla-trunk when that gets out of date in this changeset. Anthony: I'm okay with either that (+1) or the trivial recurring fix (+0), should you prefer that one.

Tagging for 0.8.2.

You are welcome and I do agree there are additional options available, but the base foundation is laid for discussion and whatever you two (and maybe when Aaron pops by) decide.

[arantius]

I've got a variety of possible opinions here. What would help me narrow them down is a clear list of what javascript 1.8 can do, that is currently not possible in a GM script today.

I.E. If we add this, what do we get?

[Martii]

arantius wrote:
I've got a variety of possible opinions here.

If I may, Johans implementation is the "next step" and I humbly defer to it. Finding a suitable XPCOM interface was next on my list... but it still leads back to using this parameter. Jesse Andrews at USO, from what I gather, is noticing the trend of making user scripts globally available to all browsers as have I. GM runs in the sandbox and other browsers run in the window scope. While this may currently provide an advantage over GM in Firefox due to lack of scalability of the JavaScript version it uses, it is a safe haven for scripts when a site is insistant upon probing for undoing modifications. Another note Mozilla engineers seem to have catered to Ubiquity's indulgence in backwards compatibility.

Olivers suggestion has merit and is quite useful if one remembers to actually use the key properly every time. Again it leads back to this parameter.

A fourth option, derived from Olivers suggestion, could be to use a Firefox preference to put the value in... but as it has been stated in the dev group this doesn't really "fix the issue".

Most PHP browser identification is using the user agent string in some form or another, however this can be spoofed to show misleading information.

Advantages of JavaScript 1.8 (and perhaps beyond with Johans commit) offers GM an "equal plane" with the other browsers. The most recent topic on uso involves the use of let and yield.

EDIT: One further note 1.8.1 is actually 1.8 build 1 from what I'm told by a Mozilla contact which is why the constant isn't defined.

[arantius]

I like Johan's version in theory. When I run it, however, I get a whole lot of:

Error: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [jsdIDebuggerService.enumerateContexts]
Source File: file:///D:/ffdev/gm_scripts/js_18_tester/js_18_tester.user.js
Line: 4294967238

[arantius]

And, in fact, if I do the simple "pass 1.8" change, and put JS1.8 syntax in a user script, I just get:

Error: syntax error
Source File: file:///D:/ffdev/gm_scripts/js_18_tester/js_18_tester.user.js
Line: 38

[arantius]

Sigh, disregard the "syntax error". Lazy copy and paste.

[Martii]

arantius wrote:
When I run it, however, I get a whole lot of:

Error: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [jsdIDebuggerService.enumerateContexts]
...

I didn't get this error myself on this platform... It would appear that Firefox for Linux, or some other addon perhaps, initialized the debugger at least once here. (I disabled Firebug, so I don't believe it is that but I do have a lot of addons that target JavaScript specifically) On both the Windows and Macintosh OS X platforms I have, neither are fully configured and thus come up with the same errors as you have shown on every script. After some digging I've discovered that the jsds needs to be initialized. A possible solution I have found is to encapsulate a portion of Johans commit with the following code:

  getMaxJSVersion: function getMaxJSVersion() {
    var versions = [0];
    jsds.on();
      jsds.enumerateContexts({ enumerateContext: function(nsIContext) {
        versions.push(nsIContext.version);
      }});
    jsds.off();

```
var max = Math.max.apply(Math, versions);
...

This appears to resolve the issue by initializing the debugger, while debugging Johan's "detection" method... and it's "back in business" so to speak. :)

[johan]

Thanks! I didn't find any useful docs on how it should be done properly; what I did was asking for a pointer in #extdev on irc.mozilla.org, and Mark Finkle kindly brought up jsdIDebuggerService's nsIContext.version and enumerateContexts. that it worked on my mac os 10.6 without that was probably (un)fortunate happenstance.

Improved variants (both working for me): above fix only, or (preferred, if it, too, works across OSes et c) run-once at service init time.

[Martii]

Johans third commit checks out here so far: :)

  PASS   Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3

  PASS   Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (10.5.7)

  PASS   Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (32bit Mozilla distro on 64bit Linux)

EDIT:
and a clean profile with 0.8.20090826.2 RC1 + this commit in:

NOTE: Only point where JavaScript 1.7+ syntax actually makes a difference in 3.5.0+ on all platforms tested... but Mozilla "could" fix previous versions perhaps. This is where the suitable component for detection comes in handy. :)

Mandriva 2008.1 i64 PowerPack w all updates (Mozilla FF 32bit distro)
  PASS   Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5
  PASS   Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9) Gecko/2008052912 Firefox/3.0
  PASS   Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
  PASS   Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Microsoft Windows XP Pro 2002 + All winupdates
  PASS   Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)
  PASS   Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 (.NET CLR 3.5.30729)
  PASS   Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 (.NET CLR 3.5.30729)
  PASS   Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 (.NET CLR 3.5.30729)

Mac OSX Version 10.5.7 + all updates
  PASS   Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5
  PASS   Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0
  PASS   Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
  PASS   Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5