Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
In nightly, @require doesn't work as intended #1592
This has got to be due to the recent injection change to use line numbers (#1404) which eval'ed each section of the script separately .. in its own anonymous wrapper, separating the namespaces, which was not intended.
added a commit
Jul 23, 2012
I think the only reason we still anon-wrap by default is the old "var sidebar" issue:
Way back in 2008 we removed it, hit that, put it back and haven't touched it. We still wrap if there is a bare return, otherwise the script just fails to run -- in this eval with lines scheme, just the one (require or script) thing would fail to run.
So right now I'm trying to reproduce the "var sidebar" issue, goal being finding a different solution to that, and removing the anon wrapper by default. So I made https://gist.github.com/3228230 and tried:
Greasemonkey development head, Firefox 15 beta: Runs fine.
Line 57 is
Greasemonkey 0.8.20100408.6, Firefox 3.6.28: Fails, same.
So this is only broken in Greasemonkey 0.8? Maybe the don't wrap "temporary workaround" won't be so temporary.
More test cases, separate files, still all in https://gist.github.com/3228230
Firefox 22.214.171.124, Greasemonkey 0.8.20100408.6:
Firefox 3.6.28, Greasemonkey 0.8.20100408.6:
Firefox 3.6.28, Greasemonkey 0.9.0:
Firefox 4.0.1, Greasemonkey 0.9.0:
Firefox 15 beta, Greasemonkey 0.9.0:
Firefox 15 beta, Greasemonkey development head:
Failure messages look like:
This is a reproduction of both style of errors mentioned in the history of this bug, in various Firefox/Greasemonkey versions. But never in recent versions of both. This makes me much more confident that the bug is squashed enough to consider fully dead for 1.0 development.
If you do
Only for "x equals". For most of the IDL properties. But the error message is extremely clear and points to the specific line in question. I'm comfortable leaving that much; use of these variable names isn't super common. And of course this is the same behavior you'd see in standard JS in a page.