greasemonkey / greasemonkey

Simple test case: http://gist.github.com/164761
Complex test case: http://gist.github.com/164763

See also: http://greasemonkey.devjavu.com/ticket/106

GM_apiLeakCheck() is designed to stop JS calls from page land and that's precisely what it does, no matter the call has been piped through the event machinery or not. It probably makes sense at the Mozilla level to process it this way and i wouldn't expect it to change in the foreseeable future -- although it never hurts digging a bit deeper...
Whatever, there'd still be a huge user-base with older FF versions suffering from this issue.

We'd like to consider calls through the event machinery as "indirect calls" and allow them, but there's nothing in Components.stack or Error.stack about that. Perhaps there's another way to tell...
I believe Firebug is able to detect that a script is an event script, but i'm not really sure how, nor if it would be usable in GM.

There is a quick solution to this. It's far from being perfect, but it has to be mentioned nevertheless: we could add a GM API function that would do the wrapping, pretty much as demonstrated in the wiki.
For example:

function GM_listen(/**nsIDOMElement*/ element, /**string*/ event, /**Function*/ callback) {
    element.addEventListener(event, function(e) {
        window.setTimeout(callback, 0, e);
    });
}

The historical position (and the one I agree with) is to not introduce GM functions that don't have to be included to i.e. grant a privilege the script would not normally have on its own. Every extra GM function added makes scripts less inter-operable with other user script platforms.

This function could easily be developed and shared via an @require . Greasemonkey needs to come up with a good way to share useful @require-able code.

Frankly, i think this is a good rule of thumb but one should be careful not to push it too far...
For example, suppose there was some piece of code all scripts were using; then i believe it would belong to the GM API, not to some tiers library each and every script would @require, even though it's technically possible to implement it outside of GM core.
A real-life example would be GM_addStyle: if you remember, i've published uso statistics a few month ago showing it almost was the most frequently used API function (it probably is with other metrics).

Back to our issue, there may be a security concern here that would be worth a GM API function. Basically, piping through a sandbox setTimeout is enough to fool apiLeakCheck. In other words, a page-land object (possibly trapped) may slip through the net and end up in GM core.

Example of apiLeakCheck bypassing:

unsafeWindow.gmPrivilegeCall = function(/**string*/ method) {
    method = eval(method);
    var args = Array.prototype.splice.call(arguments, 1, arguments.length)
    setTimeout(
        function() {
            method.apply(null, args);
        }, 0);
}

UnsafeWindow is unsafe. It should never be used. Since, unfortunately, certain things are impossible without it, it exists. We can't make it safe. You can only be safe if you can't use it. In this example, you have done exactly that. Real scripts should not do that.

If you (a script author) intentionally try, you can use it to create an unsafe situation. Thus the name. You should never use unsafeWindow. The cases where it is legitimately needed are very rare.

Argh ! I bumped the 'comment and close' button by accident ... and there is no reopen button?

Heh. Reopened via the API. But fixed.

We can't make it (unsafeWindow) safe. You can only be safe if you can't use it. In this example, you have done exactly that.

I'm afraid you missed my point here.
This is not an unsafeWindow exploit: unsafeWindow exploits only allow to reach userscript content, not the GM API. Besides, it could have been triggered through an event listener just the same.
It is a setTimeout/apiLeakCheck exploit: API calls from page-land should be stopped by apiLeakCheck, they are not when piped through setTimeout.
What you have called a "standard workaround" in this ticket description actually is a security leak that may serve evil purposes just as well as legit ones.

My original point stands. If you accept arbitrary script contents from unsafe land, and execute them (eval), then you as a script author have created the hole.

While it's true that this is a potential security hole, it is not one that we can generally "fix". We can only protect the script author "so much". There are, however, discussions about how to move forward that would help prevent situations like these. It's nice to know all the potential problems, to check that a solution addresses all of them.

If you accept arbitrary script contents from unsafe land, and execute them (eval), then you as a script author have created the hole.

I'm afraid i have to disagree here:

• In the above code, eval only serves to map a GM API function name (string) to the corresponding Function. It could work just as well without eval -- although it would be less generic or would require another mechanism to select the target function.
• Normal page-land calls (i.e. without setTimeout) trigger apiLeakCheck, whether they use a sandbox-scoped eval or not.

While it's true that this is a potential security hole, it is not one that we can generally "fix"

The only "solution" i can see so far would be to remove all references to setTimeout from the sandbox (i understand it would break an unknown number of existing scripts).

If you accept arbitrary script contents from unsafe land, and execute them (eval), then you as a script author have created the hole.

Although i believe this comment does not apply to the featured code for the reasons explained above, you are of course absolutely right that using a sandbox eval on a page-land string would trick apiLeakCheck too -- whether said string has been acquired via a XPCNWrapper or not.

The wiki states:

it should not be possible for a user script, either intentionally malicious or accidentally problematic, to cause either security or privacy problems for the end user

From the above discussion, given the current state of GM and apiLeakCheck, it seems that trying to do our best in this direction would require removal of both eval and setTimeout from the sandbox. :-/

there may be a security concern here that would be worth a GM API function

In other words: if the current setTimeout was removed from the sandbox for security reasons, there would be room for a GM_listen API method (which would wrap the event callback in a setTimeout). It would so abid by GM policy regarding new API functions.

A) That page is very new, still under discussion/development, and bears a large and red disclaimer at the top.
B) It says "should". We live in an imperfect world, and must often make compromises. I'm not sure if we could even remove eval or setTimeout, if we wanted to. Both would severely limit real scripts (eval less, but still so). The best option (IMO) is to trust the script author to be responsible, rather than removing critical tools.

That page is very new, still under discussion/development, and bears a large and red disclaimer at the top

Sure, i'm trying to evaluate the situation. :-)

The best option (IMO) is to trust the script author to be responsible, rather than removing critical tools

I agree.

Take a look at: http://mxr.mozilla.org/mozilla/source/browser/components/microsummaries/src/nsMicrosummaryService.js#1696

Using an iframe is a relatively 'hackish' way to tackle the problem, and some more investigation is probably due.

Implemented in this commit: http://github.com/Tim-Smart/greasemonkey/commit/5a9362dd9e23de853686d3630b3778ac9761411b

Still reasonably rough, needs some attention in area's of security most likely (I haven't developed extensions at all really), but succeeds in parsing HTML and XML.

Only limitations is that it requires a callback, due to the asynchronous nature of the iframe method used.

I have given this issue a shot a few month ago but did not push as far as to get a working solution.
Actually building the XML document is not a problem, however importing this document back into the sanbox throws an error because of same-origin security checks. The GM Sandbox is initialized with the userscript's target nsIDOMWindow, thus any document coming from another domain will not pass these tests.
I guess it would be interesting to dig deeper in this direction...

EDIT: had not seen your last post when i posted this, Tim.

Is this ticket about implementing the equivalent of XMLHttpRequest.responseXML or is it about implementing a method that would also parse successfully non-XML compliant HTML?

method that would also parse successfully non-XML compliant HTML

I was certain this is what we are trying to achieve when he mentioned new API for parsing a string of HTML , and that is what I have done.

XMLHttpRequest.responseXML is another kettle of fish in my opinion.

You're most probably right. I must have confused it with another DevjaVu ticket and the frequent user question of why GM_xhr does not provide responseXML. My bad. :-)

To parse non-XML compliant HTML document.implementation.createDocument can be used to create an empty document. I have an example of using this method to return a DOM from an xhr request here: http://userscripts.org/guides/9

While document.implementation.createDocument is an option, it has several limitations that I won't go into detail about. But it is possibly worth a look.

EDIT: Also stabbed at implementing responseXML: 1266792

Also stabbed at implementing responseXML: 1266792

I believe this issue is worth opening its own ticket (also made a comment on your commit page).

Idk... This isn't really a big issue. The workarounds we have from within the current context GM are fine. Besides, forcing scripters to find other ways of handling response xml / html is the way to go.

forcing scripters to find other ways of handling response xml / html is the way to go.

What do you mean?

I mean, don't make it easier for them to work with it. Creating whole objects out of XML is slower, and if they used regular expression or just regular string methods, it would be better.

I think of it in terms of this being nothing special: we were able to do it before, and it wasn't that great anyway.

I personally think this would be a useful feature. There's a few proposals, but I'm currently unsure which works/works best. So tagging for v.next; I intend to research this a bit, and if it proves infeasible or too difficult it may be postponed.

By the same logic with which you guys shot down my issue with GM_xmlhttpRequest + POST ("you can already do it, you just have to know what to do"), this should be abandoned as well.

I quote:

Making browser APIs comfier is the domain of @require libraries.

I vote -1. The benefit is minimal (saving one line of code?) and it's a perfectly normal JS/AJAX thing that a programmer needs to know.

Btw, it's not just saving one line of code. Maybe I'm an idiot, but it took me a long time to figure out why the hell my POST requests weren't working at all (I had about 3 months of experience in any programming at all at the time).

On the other hand, I figured out how to "parse a string of html" almost immediately.

I could easily be wrong. Show me the user-script-land code that can start with a string of HTML, and give you a DOM document, and I would agree. Unprivileged scripts can only parse valid XML though, to my knowledge.

Tim-Smart's implementation is the only one I've seen that seems to be able to (I haven't built and played with it yet to verify its capabilities and/or pitfalls) get a non-clobbered DOM (including things like script tags, head, body, html nodes and their attributes) that can be queried with the DOM tool chain (querySelector, XPath, getElement(s)By... et cetera).

The workarounds available work for trivial cases only, where a clobbered DOM is okay, and manual stuff using regexps will be orders of magnitude slower than browser native DOM generation code, if they are correctly implemented, and trivially broken when not.

I'm also +1 to this kind of feature, despite having pragmatically settled in my own user scripts for a @require http://ecmanaut.googlecode.com/svn/trunk/lib/gm/wget.js which creates an iframe after having massaged away as much dangerous javascript as it can from the HTML string.

give you a DOM document

I'm pretty sure it's possible, and even if not, I think this whole feature would be overkill. The most important thing to realize is that it won't enable us to do anything we couldn't ultimately do before.

How about doing something like giving us the ability to automatically download files (with custom file names of course)? I've implemented this with the little experience I've had in my extensions.

@Johan:

Maybe I'm missing something, but can't you just do something like:

var tempDiv = document.createElement("div");
tempDiv.innerHTML = someResponse.responseText;

// now you can:
document.evaluate(".//a", tempDiv, null, 6, null);
tempDiv.getElementsByTagName("a");

// etc... ?

What does building a fully fledged DOM really give you?

Quoting above and elaborating further: intact script tags (and their proceedings -- so <script>document.write('x');</script> comes out as such, without any trailing appended "x" -- which IIRC happens with my own wget.js hack), as well as intact head, body, html nodes and their attributes.

Example:

var div = document.createElement("div");
div.innerHTML = '<html lang="en"><head><title>ow!</title></head><body background="red">Ugh</body></html>';
alert(div.innerHTML);

...will show you <title>ow!</title>Ugh. A fully fledged DOM enables you to use absolute XPath references (/html/head/script[3]/@src for instance), discern where in the document a node is, find contents, attributes et cetera even of nodes that get squashed when doing the innerHTML hack, introspect at un-executed javascript code (especially inline code), and so on.

It's quite probable that you yourself won't ever need or want any of these properties, but others (both more and less advanced scriptwrights than yourself) do.

Creating document from string is available without GM API.
I recommend this article http://nanto.asablo.jp/blog/2009/10/29/4660197 (Japanese),
and this code snipet, http://gist.github.com/164430

Removed the 0.8.3 tag. This seems controversial. I hope to take a look at all the possibilities mentioned and move forward from there.

Like many other good tools, it would be a lot more beneficial having an html DOMParser implemented in the underlying browser than in Greasemonkey middle-ware.

How about a 'Configuration' tab, which would be displayed if you go to 'Tools' -> 'Add-ons' -> 'Greasemonkey' -> 'Options', and the "Manage User Scripts" tab would be displayed by default if you right click on the monkey's face at the bottom of the screen.

Johan and I have both expressed interest into incorporating the list of scripts into the Add-Ons dialog (alongside full fledged extensions). This would leave the Greasemonkey Options dialog to expose global settings, like this. I would expect that is the path we'll take.

Ah that makes good sense.

Johan and I have both expressed interest into incorporating the list of scripts into the Add-Ons dialog

Do you mean there would be a "scripts" tab alongside the "add-ons", "themes", "plugins", etc, tabs of the add-on dialog?
Sounds like a very good idea to me. :-)

Much like Stylish does it, correct?

That would be really nice. Also reading additional non default meta keys would help out users to see which script they have ( i'm referring to @version for example (it's useful when users are reporting bugs in specific version of userscript ))

Something similar to what Stylish has would be great.

Johan and I have both expressed interest into incorporating the list of scripts into the Add-Ons dialog (alongside full fledged extensions).

Could you provide a link to the issue # please? A quick search didn't help (perhaps I should just look harder =P )

I'm quite conscious of trying to not go offtopic but I'm interested to find out how script ordering will be handled after changing to the addons dialog? And also, personally I would prefer this to the addons dialog so would you be willing to leave the Manage Scripts dialog in the script in one way or another (only via the menus for example).

I don't think there is an issue about this yet. Most recently on the list, at:

http://groups.google.com/group/greasemonkey-dev/t/c4755e26c01c912e

"leading (and trailing) slash means pure regular expression"

Any word on if, or which version this will be implemented in?

Webmonkey implementation patch: 298f008

So, as indicated earlier, there are choices to make on this issue. I'd love to have both yours and Anthony's views about it.
This WM commit takes radical steps and should be seen as a proof-of-concept rather than a suggested implementation for GM. As it is, it even introduces a GM_apiLeakCheck() bug: because a script now runs on its own behalf (vs. greasemonkey.js one) there is an unknown "file:*" caller in the stack.
Let me attempt to make a long story short....

I've been confronted to 2 main constraints:

• John J. Barton does not want lots of GM-specific code in Firebug core -- something i tend to support.

• Whatever the GM-specific Firebug patch, it is delivered in Firebug-1.5 which is only compatible from Firefox-3.5 up. On the other hand, this patch could so rely on a Gecko-1.9/FF-3.5 feature.

As a consequence, a very small FB patch was crafted and committed: it relies on Component.utils.evalInSandbox() being fed the actual file path of the GM script run (instead of greasemonkey.js currently).
In other words, the injection logic must be adapted, at least in debug mode, if we want it to work:

• @required source files and the script own source file must be evaledInSandbox() in turn; they currently are concatenated and run as one big script. This already is quite big a change: although it should not be a problem in the case of actual libraries, i suspect some use @require in ways that this change could break.

• Of course, @requires and the script source cannot be wrapped into an anonymous function any longer. At a minimum, @unwrap is replaced by (or interpretated as) some kind of debug mode. I believe the modern sandbox is able to cope with GM scripts (contrary to what happened with "reserved" variable names in the past) but i suspect this would still break a few and at least raise your guys' suspicion :-). Nevertheless, debugging in these circumstances offer significant advantages: you can inspect your script objects (i.e. the sandbox members) at any stage of your script's execution. Pretty neat. :-)

Of course, we can limit these impacts by putting in place some kind of debug mode, leaving the injection logic untouched in normal mode.
But we don't want scripts to break just out of GM being switched into debug mode either. By this i mean: i'd rather have the injection logic unchanged when switching mode.

I guess these more or less are the parameters of our issue.

Of course, @requires and the script source cannot be wrapped into an anonymous function any longer

This is a show stopper. We tried to remove the anonymous wrapper by default in the past -- it was bad. The last release specifically added this behavior back in. See #108.

P.S. I hate markdown syntax.

I remember we've talked about this "sidebar" issue some time ago on @gm-dev. I remember i had tested it then and it was ok (don't remember my exact GM setup at the time, but i'd say FF3.0 and GM-8.2). I just tested the "sidebar" issue on a current WM snapshot with FF3.5 and it works like a charm.
That's why i've written above that i believe the modern sandbox (FF3+) is fine with that. Is there something else i have missed? Are you worried by backward compatibility with older FF versions? If so, perhaps you could consider a debug-mode that would leave normal-mode injection untouched?

I'm not sure what might have changed in WM, but in GM this script:

// ==UserScript==
// @unwrap
// ==/UserScript==

var sidebar;

Fails with:

Error: Illegal value
Source File: file:///.../gm_scripts/unwrapped_script_test/unwrapped_script_test.user.js
Line: 5

If you can identify that WM definitely does not exhibit this behavior, and figure out why that is, perhaps we could import a fix, and then begin considering this.

Ah; thanks for the elaboration. (I puzzled a bit looking at the uninformative commit message where you made @unwrap the global behaviour in webmonkey, without anything like the above discussion -- now I get more of the picture.)

It's a bit of a hairy situation. If we can get some stuff into Mozilla's own test suite that triggers on sandbox regressions like the one that hit us, so they don't start breaking a ton of user scripts all of a sudden again with changes happening far below us, I think I would be fine with having @unwrap behaviour for all scripts on modern enough mozillas.

The whole separate issue of one Greasemonkey fits all mozilla versions is something I wonder if it's the ideal model for evolving GM. It certainly makes this kind of hackery a good deal trickier.

Oh, you're right, Anthony: i had forgotten the "var" keyword ("sidebar" works ok without it). So, this is still an issue and i have no solution to it so far. I'll give it a deeper look although i'm not too optimistic, there probably isn't any easy general solution to this namespace issue at our level, beside wrapping.

Fixing Mozilla once and for all would be the best option but i suppose it's a longer term adventure -- that is, admitting the current sandbox behavior has no good reason to be at the Mozilla level. My opinion is: we should work on this, but still put in place a shorter term strategy (FB patch of some sort).

I've also crafted a FB patch that works with the GM injection logic pretty much as it is (wrapped). One big disadvantage is: you cannot inspect your script elements through the DOM side-panel any longer. Moreover, It's an heavier patch, filled with GM specific stuff.
On the other hand, with what has already been committed to FB, it should now be possible to hot-patch FB directly from GM to inject these remaining bits.
John tends to be against heavy FB hot-patching as well as big GM-specific FB patch. However it seems he really is sensible to our GM cause. So, there's still hope we can come to a solution. :-)

Finally, there's the question of getting rid of the wrapping altogether (admitting the sandbox issue is resolved).
Beside "namespace collision", there initially was a security objective to it. I guess ApiLeakCheck() is enough protection, although it's a slightly different topic: the former is about making all script elements unreachable from page-land while the latter is "only" about forbidding GM API calls from page-land.
And ApiLeakCheck() has its faults too: #1001... :-/

I forgot to say i do agree with you Johan: supporting all these FF versions is a heavy legacy. Do people who still run FF1.5 or 2 today really care about new GM features? Is it worth holding everyone else (i suspect an overwhelming majority) back for these few?

The same could be asked about existing userscripts: how many of them rely on wrapping? I mean, it's not like userscripts are super-stable in time at the moment anyway: they so often break because of a slight web site change... If you're using "var sidebar" in your script and do not wrap it somehow, is it really too much to ask you just change your var name or wrap the problematic code yourself?

My take for WM so far is: the sandbox is the JS scope userscripts run in; that's just how it is. It's a slightly special environment (XPCNWrappers, sandbox restrictions, etc), it's not 100% page-land like; Nothing big but one still has to know about and deal with it.
On one hand, i'm ready to act at the mozilla level to try bending the sandbox our way: after all, it seems GM is the biggest Sandbox feature user by far. And sandbox bugs should be fixed at the sandbox level, shouldn't they?
On the other hand, script writers must acknowledge and adapt to their (unfrozen) environment. Userscripts bugs should be fixed at the userscript level. And i'm willing to put a good deal of work in making the whole userscript ecosystem more dynamic: it should be even easier to create, debug, update, depend on or fork userscripts (on the developers side).

This being said, i understand GM has a different position and attempts to maintain a frozen interface between userscripts and the sandbox.

If you're using "var sidebar" in your script and do not wrap it somehow, is it really too much to ask you just change your var name or wrap the problematic code yourself?

Ultimately, yes, IMO. Because we have no control over what happens, and the message is so cryptic, it's a bit much to expect any and every author to know that such a strange restriction exists (you can't choose particular variable names).

Then perhaps we could list forbidden var names, publish them in the wiki and tweak the error message accordingly. Make sure people only bug once...

There's another solution: as all these var issues come from our sandbox having a XPCNWrapped prototype, we can just drop it. It's a bit radical, but then we'd have a clean JS scope. After all, we stuff it with lots of complex and pretty much useless stuff (another legacy, from the time scripts ran inside the page?) then we cry when people experience namespace collisions. ;-)
This could also be an optional behavior: we could add a @clean header tag specifying a minimalist scope (i.e. no XPCNWrapped Window prototype) where no such collision may occur...

One way or another, i feel like we have to move on this issue: the current injection logic being too "hackish" is the reason why we cannot debug it in a simple way, imo.
It probably grew up this way slowly, mainly for the sake of backward-compatibility with previous GM script environments, but i feel like it is now begging for a clean redesign.
Just my $0.02...

There is an official Webmonkey release, in case you want to experiment with what we're talking about here.

Olivier: Sorry, but you completely misunderstand the situation.

The sandbox exists as it does today expressly to implement security, isolating the user script (with its privileged functions like GM_xhr) from the scripts running in the content page. The problems discussed here are not "legacy" or "hackish".

As you know, GM_xhr (like other GM API functions) is protected by apiLeakCheck, not by script wrapping:

unsafeWindow.GM_xhr = GM_xmlhttpRequest;

The purpose of wrapping in current GM (and the reason why it has been reintroduced) is to offer scripts a "virgin" namespace.
Namespace issues come from the (XPCNWrapped) nsIDOMWindow prototype, which has nothing to do with security and is not necessary per se either: the window and document sandbox shortcuts would be enough to access the underlying web page.
The reason why there is a window prototype is (old!) backward compatibility with scripts written at the time when they were injected right into the window scope (pre-sandbox era).

To cut a long story short: the reason why there is wrapping today is legacy from old times, not protecting privileged API from page-land.
What part am i misunderstanding, Anthony?

As you know, GM_xhr (like other GM API functions) is protected by apiLeakCheck, not by script wrapping:

This statement is not totally correct, depending on what you mean by "script wrapping". By default, there are two wrappers in place.

Anonymous function wrapper.

Its roots are indeed in the very early GM method of injecting scripts directly into the page. Since JavaScript is lexically scoped, creating a function provides a space for the script (said function's contents) to define any variables it wishes. This was critical when scripts existed directly in the page, so as to not overwrite and break content scripts by accident.

Today, it might have been removed, except for the issues already discussed here. We in fact did remove it, but only then discovered the problems that this causes, and thus reverted the change. It won't go away until (at least) this test case executes correctly without it.

XPCNativeWrapper

Stock Firefox has two execution scopes: chrome and content. Greasemonkey creates a third, in between: user script.

XPCNativeWrappers exist to allow a higher-privilege scope access to objects (potentially) created in a lower-privilege scope, without leaking those higher privileges. Ultimately, because JavaScript is such a powerful and flexible language, a variety of things can go on that one might not even realize. It's very hard to explain, and I no longer have quite enough details in my head to do so perfectly, but:

(Disclaimer: the details here are not perfect, some I know are wrong, some I just don't have the time to check now, but the general underlying theory is true.) Imagine chrome code calls i.e. if (contentDocument.title.match(/.../) { ... }. This seems benign. But the content document might have assigned a function that does something else to the document.title.valueOf() function, and then this happens. The function that the content scope defined (content scope = it could be anything, even malicious) now runs in the chrome scope, to get the value, to match it against the expression. This is a serious security hole.

Thankfully, XPCNW exists to allow us to access the object, but only get "safe" values exposed. This was the fix applied, to an old security hole. Create a sandbox, give it XPCNWrapped access to the document, and things "just work" but safely. Almost. The prototype, the wrapped document and window properties in the sandbox, and the rest, are all added to get us as close to "just work" as we can.

The purpose of wrapping in current GM (and the reason why it has been reintroduced) is to offer scripts a "virgin" namespace.

Again, this depends on what you mean by "wrapping", but is answered above.

Namespace issues come from the (XPCNWrapped) nsIDOMWindow prototype, which has nothing to do with security and is not necessary per se either

Are we sure that this is the problem? I agree that it has nothing to do with security. But it is very critical for that "just work" factor. We want user script authoring to be easy, and one way we accomplish that is by making it as close to regular content-script authoring as possible.

Imagine the user script sandbox did not have this prototype. Would alert() work? How about prompt() or frames or top? Would they only work if prefixed with window.? How would a new user script author know this? How many existing scripts would stop working?

We inject the prototype, so that we don't need to know or worry about all these possible cases (and others). They're available and "just work".

The reason why there is a window prototype is (old!) backward compatibility with scripts written at the time when they were injected right into the window scope

This is incorrect. The real reason is explained directly above.

To cut a long story short: the reason why there is wrapping today is legacy from old times, not protecting privileged API from page-land.

Which wrapping? Ultimately, both exist because they're the best way we have found yet to satisfy our requirements for security and ease-of-use for authors. (Note that I said "yet"! We're open to change, but we're not open to gains in one area that also cause losses in other important areas.)

As you know, GM_xhr (like other GM API functions) is protected by apiLeakCheck, not by script wrapping:

This statement is not totally correct, depending on what you mean by "script wrapping".

By "wrapping" i meant "function wrapping" in all the above post. The only time i talked about XPCNWrappers i mentioned it explicitly. I'm sorry if there's been any ambiguity about that.
As a reminder, function wrapping is critical to our discussion because it is the reason Firebug debugging cannot currently work.

Namespace issues come from the (XPCNWrapped) nsIDOMWindow prototype, which has nothing to do with security and is not necessary per se either

Are we sure that this is the problem?

Yes: you can easily test it yourself by using unsafeWindow as the sandbox __proto__ on the above test case.
I researched this when we talked about this topic on gm-dev earlier this year. I don't remember the details exactly, but i could research them again if needed.
One gets hints inspecting a XPCNWrapper with Firebug: you see that (target) properties appear as (XPCNWrapper's) getters. As it is not allowed to "override" a getter with a var statement, var sidebar throws an error (overriding XPCNWrapped window methods works fine). I'm not sure XPCNWrappers really use getters and so on, but that's how they appear and behave, and i believe it helps seizing our problem.

Imagine the user script sandbox did not have this prototype. Would alert() work? How about prompt() or frames or top? Would they only work if prefixed with window?

Yes: if there wasn't the window prototype, all window members would need to be accessed through window.
Our problem is that we want a bit too much: we want window properties in the sandbox (direct access), we want them safe (XPCNWrapped) and we want them overidable. We cannot have all that unless we use function wrapping (in which case we cannot have FB debugging, objective of this ticket).

How would a new user script author know this? How many existing scripts would stop working?

I am not proposing to suddenly change the default sandbox: i guess it would break pretty much all existing scripts.
What happens is that you do not want to drop function wrapping for the reasons stated above (sidebar test case), and i'm trying to make Firebug debugging work. It seems that, for the latter to be possible, something will have to change somehow (if only optionally, e.g. using a @tag).

We want user script authoring to be easy, and one way we accomplish that is by making it as close to regular content-script authoring as possible.

Yes, i understand that. But did it have to be as close as that?
After all, a userscript is not running in the same environment than a page script (and i guess we should not let people believe otherwise): it has to be extra careful when touching the page, adding events, etc. Altogether it's closer to chrome coding than page-content coding. I suppose we could have done just fine with window and document (perhaps a few others): would using window.top instead of top be such a big deal?
If you were creating GM from scratch today, with the sandbox and XPCNWrappers as they are in mind, would you chose the window prototype+function wrapping design? I think i wouldn't.
I believe what has imposed this solution is the fact that userscripts used to be injected right into the window scope. From then on, if only for backward compatibility with existing scripts, the window prototype was a no-brainer when switching to the sandbox design. Then, to avoid namespace conflicts, function wrapping had to be (re-)added...
That's why i wrote that i believed the sandbox is the way it is mainly for historical reasons.

I think a good solution, and potentially more developer friendly method, is to rethink the @unwrap metadata key.

Maybe treat scripts with @unwrap enabled , as in a sort of "debug" mode. End-users of a script will highly likely not need Firebug support, whearas developers will. So if a @unwrap is specified, then include the injection logic that enables Firebug debugging.

This will then:

• Meet the needs of developers in need of Firebug support
• Keep the security of the current "sandbox + anonymous function wrapper" model intact for the majority of developed scripts.
• Affect the smallest amount of scripts, as present scripts with @unwrap will still suffer the same penalties.
• Therefore meaning developers run into no nasty surprises.

EDIT: In the latest commit (7904dbb502c9996d9143cd9472409c74aa503ab3), maybe previous commits as well, when a user is using the latest Firebug aka 1.5.x.0a23, 'greasemonkey.js' appears in the script selections when using a User Script on http://www.google.com/ homepage. It probably isn't limited to that either...

I think a good solution, and potentially more developer friendly method, is to rethink the @unwrap metadata key.

I thought about that but found caveats, like:

• a header @tag does not seem to be the right way to enable a debug mode: typically, you'd switch to debug mode at development time, or when a script breaks. Header tags are read and set (in config.xml) at install time. If there was a debug mode, it'd be better to make it a switch somewhere in the UI for example (although that would raise other issues: e.g. it may be confusing for normal users -- non script developers), or perhaps in a dialog appearing when a script crashes ("this script crashed, would you like to debug it?")...
• changing the injection logic when switching to debug mode might raise new bugs, for example if the script uses something like var sidebar. Ideally, we'd want the debug mode to be innocuous in itself

This being said, if we can't come up with a better solution, it may still be better than nothing.

In the latest commit (7904dbb), maybe previous commits as well, when a user is using the latest Firebug aka 1.5.x.0a23, 'greasemonkey.js' appears in the script selections when using a User Script

This will happen on all GM versions when using FB-1.5a22+. It is caused by the FB patch allowing sandbox scripts debugging.
Note that it shouldn't happen on a "stock" FB install because extensions.firebug.service.filterSystemURLs would be set to true.

This update: http://github.com/erikvold/greasemonkey/commit/97cbac33586f1c1f824a2a1ec1fd5297f9e0e362 creates a commandFuncWithString method which is a chrome-side method available to Ubiquity which calls the same function as commandFunc but accepts a string param. It does not change the arguments of the GM_registerMenuCommand available to userscripts.

I don't like (or perhaps understand) this commit. Why do we need to create a separate function, referenced in so many places?

I'm still a bit lost on this one myself... can you spell it a bit more?

Why do we need to create a separate function, referenced in so many places?

The

GM_registerMenuCommand(commandName, commandFunc, accelKey, accelModifiers, accessKey )

this.browserWindows[i].registerMenuCommand(command);

which is defined in /idl/gmIBrowserWindow.idl as

void registerMenuCommand(in gmIMenuCommand menuCommand);

gmIMenuCommand is defined in /idl/gmIMenuCommand.idl, and the doCommand method is defined as:

void doCommand();

Without inputs, which means that no argument will be passed to commandFunc, even if a userscripts provides GM_registerMenuCommand(...) with a function that accepts an argument.

Another way to put this is that in /content/browser.js

GM_BrowserUI.registerMenuCommand = function(menuCommand) { ..

The menuCommand.doCommand does not accept an input string, and this is a shared issue with the the rest of the references made to it.

So my thought was to add the following to the menuCommand.idl

void doCommandWithString( in AString inputStr );

which would be available in chrome for other firefox addons, namely for a greasemonkey ubiquity command I've worked on http://r.evold.ca/greaseubiquity.

Doing the following did not seem like a good idea:

void doCommand( in AString inputStr );

because it impedes the possibility of a more complex input, and I could not come up with an acceptable dynamic input to handle any possible JS input.

Another reason to include this patch: http://jetpackgallery.mozillalabs.com/jetpacks/118

Seems like there's already a flexible and reusable solution in place, at that link. Just @require it and use it, right? How is it insufficient?

Hehe was just about to post something like this, except slightly different...

You should be able to pass flags in. I usually pass in -p --no-remote to GVim, so new files open in a new tab within the same editor instance. Firebug implements this quite well I believe.

That's a good idea too. That belongs in #1012 I'd think, it's part of making the editor configurable.

Potentially See Also: #1018

Against which version of GM? This should have been fixed in #1018 as mentioned.

I believe there is a consensus around this (admins acknowledge this fact).
I'm afraid reaching a consensus on how the code should look like would be much harder (if only possible in a reasonable time frame): there are several ways this could be done and, to efficiently discuss which one is best, one must have a deep understanding of how the current code works (a knowledge very few people have). This is without counting on the inevitable regressions such a code refactoring would create.

I believe several attempts have been done in the past (eg see old SVN branches) and none has made it to a point where it could be merged back into the master branch. I also suspect this was done by people while they were trying to get into the current code...

Fwiw, i've done quite a lot of work in this direction myself if you're interested (see Webmonkey).

Dev discussions belong on the -dev list, not on the user support wiki. There's no question that the code quality is sub optimal. But yes, agreeing what "optimal" might be is no small task, nor is moving the whole code base in that direction without breakage.

This should be a small and safe change. Tagging for v.next.

Wouldn't this fall under the same category as file:// with xhr and @include ?

Yes except A) It's much much more difficult to predict the URL of a .mht file on the user's machine and B) they're not indexes of the filesystem so they don't reveal their own presence like file:// does and C) they're less likely to contain sensitive information.

Just as a FYI, here's a very small snippet of USOs main page archived as a MHT accessible by view source:

...
<link type="text/css" rel="stylesheet" media="screen, projection" href="unmht:///file.5/home/user/Desktop/forums.mht/screen"></link>
...

Note that the current username and desktop location is exposed as well as where the mht is stored... any thoughts?

I vote -1. There are too many possibilities, that change over time. They are too specific to the author (you might use one template, someone else uses another).

It's not hard to keep a template file for yourself, and copy/paste from it. And this works for everyone, no matter what they might want the template to be today, and what they might want it to be tomorrow.

I want the possibility to add and save my templates but not for some to be shipped with Greasemonkey.

Actually the main issue is that, if I paste a template which require the libs I need, this does simply not work. I have to install this script and not just click on new script and paste my template. So this is really a pain to create a script which dependents on a lib.

Ah I see, the ability to add user-defined templates for new scripts would indeed be much better than my first failed understanding. The incompatibility of today's "New Script" dialog with @require (which is newer) is definitely worth fixing as well.

The incompatibility of today's "New Script" dialog with @require (which is newer) is definitely worth fixing as well.

It's true the new script dialog does not allow usage of several header features like @require and @resource (and perhaps @unwrap). Shouldn't we open a new ticket to deal with this?

That's a very good question. As I begin to think seriously about how to get this dialog to deal with all the possible different possible bits that the user might want to include, I start to realize that templates might be the best/only option.

I'd imagine that the dialog would then become a big (XUL of course, but HTML terms here because they're easy to understand) < textarea >, along with a < select > of existing templates, and a button to save the current text as a template (and delete the selected template?) Then there would be one (or more) default templates, perhaps the defaults would not be delete-able.

Perhaps a "simple" and a "complex" template, the latter with the "minimum" (name, namespace, description, include) that a script "should" use, the latter with all the options (resource, require, exclude, etc) which can be kept or removed. Whatever we end up with, this stub script is installed, and the editor is launched.

I'd imagine that the dialog would then become a big (XUL of course, but HTML terms here because they're easy to understand) , along with a of existing templates, and (...)

I'm sorry, i'm afraid you forgot a couple words in the above sentence. That makes it a bit of a guess game. ;-)
I assume you are proposing to use a text area to print/edit a template (instead of specific input fields as we have now), as well as a list of templates you can select/add/remove from, right?

I'm worried about something: dependencies.
It might be good to use a file-picker to get the target file path.
Also, ideally we'd like @require and @resource tags to feature a relative path (not an absolute local path): it's simpler, clearer and more portable.

I didn't, but markdown failed me. Inserted some spaces so that it doesn't eat my < > tags.

The dialog you are describing sounds great for me !

As a developper I think it will also be great to be able to update @require @resource @include @exclude from an edited file. I was thinking of a "reinstall" button in the "manage scripts" dialog. But as a developper, i think the best would be an option that i would enable when i develop which would reinstall all modified scripts at each page load.
I'll post another feature request for that.

Few users of my script[1] has also reported same problem that they're not able to install it after upgrade to 0.8.20090920.2
No one said that there were any errors in the Error Console.
But after few 'retry' they were able to install it (few refreshes).
So far only those that were using dutch localized firefox were having problems.

[1] - http://userscripts.org/scripts/show/11336

@vBm

 COMPLETE  I'll add to this after I hop around to the various machines.

Setting javascript.options.strict true and javascript.options.showInConsole true no Errors in console. I did however notice that "installed successfully" is shown in the monkey menu when installed. Not sure if that's Dutch. ;) :)

 PASS  Clean profile migrated to Mozilla/5.0 (X11; U; Linux i686 (x86_64); nl; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 with migrated 0.8.20090920.2 installed 11336 on first try and executed.

 PASS  Dirty profile migrated to Mozilla/5.0 (X11; U; Linux i686 (x86_64); nl; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 with migrated 0.8.20090920.2 installed 11336 on first try and executed.

 PASS  Dirty profile migrated to Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) with migrated 0.8.20090920.2 installed 11336 on first try and executed.

 PASS  Dirty profile migrated to Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; nl; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 with migrated 0.8.20090920.2 installed 11336 on first try and executed. (10.5.7)

I had this issue, until I changed the extention folder to a clone of my fork. Never found out what caused it though.

navigator.userAgent returns "Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3"

EDIT: A clean Firefox profile seems to fix this issue. Still a bit of mystery on why this happens.

I had a user report this issue to me, and after going back and forth with him, he said one day it "just worked."

Then today after getting one of my scripts ported to Opera, I wanted to bring the new Opera version back to Greasemonkey to make sure it still worked with the changes. I dragged the file from the Explorer into an open Firefox window, and Firefox showed the source, with the ribbon at the top and an "Install" button. But clicking the button had no effect!

After playing around a little I noticed NoScript was disallowing scripts on file://. For the heck of it, I allowed scripts for file://, and the GM installation dialog suddenly popped up, and then the installation proceeded normally.

Funny thing was when I tried again with another script, it wouldn't install, but the moment I told NoScript to disallow scripts on file://, the dialog appeared and installation was able to proceed. Same effect when I set NoScript to "Allow scripts globally" - installation would no nothing until I changed states in NoScript again.

I have not yet tried disabling the NoScript extension altogether.

Surprisingly (to me), disabling the NoScript extension had no effect, except then I didn't have a switch to turn on and off to make it twig :(
Neither did a clean profile.
But perhaps that's the way file:// urls are supposed to work?

If I see the problem happen with an http:// url, I do some more testing.

See Also #1075

Maybe perhaps a switch on the build.sh to have it create the date only for local testing purposes? Otherwise, it would definitely be a lot less to type for those keyboard challenged. ;) :)

Maybe perhaps a switch on the build.sh to have it create the date only for local testing purposes?

I support that. Incidentally, that's what i did with Webmonkey: build.sh accepts a '-r' (optional) switch, standing for "release", that removes the date from the build version. ;-)
Following on the same idea, and now that we've switched to git, it'd probably be more meaningful to use the commit SHA1 instead of the date to single out non-official builds...

Just so we're clear, what's the benefit of having either the date or the SHA in the version number for development builds?

For my own development: I always set the "right" version directly in install.rdf (so, during development, it is the "next" version, which will be later than any public builds), and my build script does not alter it.

The biggest benefit is not having to change to Mozs scheme of 0.8.3a and change the install.rdf for local development before posting as a branch on GitHub. A lot of the time, alpha software should be automatically versioned to eliminate local conflicts. Some devs have multiple Alphas, so showing it in the browser under Tools→Add-ons would be helpful when coming back from a break to recall which was installed.

As far as Olivers commit, I would recommend reversing the logic to be more congruent with what you are looking for Anthony. (e.g. -alpha or the like to generate the date field at whatever position). As you can see it can be a very small change to build.sh with benefits for local testing.

I'd appreciate if you refrain from zero-content comments like "... more to come". I really don't need to get an email notifying me that you've said that. Please just comment when you actually have something to say.

Sorry... but that is the way I'm doing it... I do make several changes to make it more clear, especially for you, since everyone seems to get confused by my posts. Until I am more comfortable with GitHub, and I'm still working with GitHub directly on fixing a few of their own issues. I prefer it that way and it's better than seeing EDIT EDIT EDIT EDIT EDIT EDIT EDIT, etc. Usually after about 30 minutes you can check, if its from me, as I have moved on. (compare your email on this to what is here now)

The GitHub system sends an email notification to everyone participating in the issue when you place a comment, and not when a comment is edited. Getting an email notification that there is "more to come" is not helpful to me. It would seem that you can simply make your comment and not worry about the markup. Edit to fix, if you've made an error.

"especially for you, since you seem to get confused." Please refrain from insults, especially those that are personally targeted.

It is not an insult... I expanded my perception on the reply... if you have a problem with it go "dark" again. You seem to have unresolved political issues that should be vacated. Be professional and be civil... I am for sure and the rest of the team that I work with concurs. I've done my best to cater to your "sensitivity" but sometimes that doesn't work... so I WILL edit within my approximate 30 minute window if I feel the need. The ... more to come is indicating that I have more thoughts to come. :)

As far as "confused" you have stated this on multiple occasions on greasespot and also Google Groups... so how about following your own advice? I am actually the one who "complained" that you were being obnoxious and rude by telling people that they were confused. In short, ending your politically motivated straying off topic, learn to live with it.

As far as this issue goes... your issue is trivial at removing the date field... I'm trying to work with you and everyone to meet at a cross-roads.

Just so we're clear, what's the benefit of having either the date or the SHA in the version number for development builds?

Mainly to identify shortly what piece of the code is hiding inside a XPI/install. :-)
When a (non-official) build is built and moved around (installed in a profile, posted online, etc), presumably for testing/demo, i believe this is about the most important information to feature: normal users only deal with official builds, developers work with git commits, build testers must be able to know/report what they have tested in a concise way (e.g. commit short-version SHA1).

In fact, my opinion is that every single time someone runs build.sh in the world it is relevant to include such a unique identifier, except for the few times a year you actually build an official release. :-)
That's why it's probably best to include it in the build version as a default, by the way: it lessens the probabilities that confusing non-official builds with official version numbers get posted online without any ill intent.

Excellent points Oliver... I am +1 now on setting switch to "release". :)

Chiming in to say... definitely agree with getting rid of the date. I think it's pretty silly looking, and probably confusing to new users.

CONFIRMED On my Mac OSX 10.5.7 the sample user script locks up the machine for an indefinite amount of time. The "odd" behaviour your users have been describing, and I experienced as well, is the system trying to keep up with the events.

I don't really think that this is a GM issue though and more of a FF issue... you might want to submit it to bugzilla. Unfortunately I don't have time to build an extension at the moment that mimics your xhr... but I'm pretty sure that it's not a GM bug. Have your users tried an older version of Firefox?

PASS Using Firefox 2.0.0 on the Mac, the script runs as expected... however v3.0.0+ of FF appears to hang. This is looking more like a Moz bug.

Hmm... Could you also try this sample?
http://dain.se/gm/bug.html

It is a regular (non-GM) javascript that does an xmlhttpRequest for the same auth requiring page. I had one of my users try this, and he said that it didn't cause the bug for him, which led me to believe that it was indeed a GM bug and not a FF bug. Remember, the bug is only triggered when you are required to enter the credentials, so you may need to restart your browser to clear the cached credentials. Thanks!

I'll try it for you... but it's comparing apples to oranges... the restricted xhr doesn't go through the same "hoops" that the XPCNativeWrapper and Sandbox GM xhr uses... the problem probably lies somewhere between the Sandbox and Firefox itself... There is one other check that GM isn't doing but I personally have not seen the need for it but I'll give it a whirl as soon as I find it again LOL :)

PASSRestricted XHR in FF 3.5.3 on OSX 10.5.7... as I stated above, I expected it to pass because it's not the same as a privileged chrome:// xhr.

Ahhh here is the missing check... planned for 0.8.3 in issue #1008

So I've added a check to every downloaded "script" to see if it begins with <!DOCTYPE. If it does GM will not try to install it, and will load the page in the browser instead.

Fixed with http://github.com/Tobbe/greasemonkey/commit/9fda98c09dd1a6eedad80e1be1ec477c80ceb80b followed by http://github.com/Tobbe/greasemonkey/commit/91b6a83e39a5243a4d9a36dccb75fdedd1708c85

I know this will probably not catch all web pages, but I think most modern pages begin with a doctype declaration. Could also add a check for <html> I guess, but no matter what we add we will never be able to detect all web pages.

Probably better to check the mime type in my opinion. Should only accept text/javascript and application/javascript files.

The window watcher, last time I checked and commented on devjavu before it went down, wasn't returning the correct content type... thus, last time I checked, this was definitely a Mozilla issue. I am still probing around the FF source to see what's up... but this time of year I get super busy. Even if the Moz engineers fixed this, it wouldn't be backward compatible in the browser. :\

http://example.com/myscript.user.js?

I realize the <!DOCTYPE check isn't ideal, but does it hurt to have it? It's backwards compatible in the browser.

I'm not writing a website to host user scripts. I'm using github to host my userscripts, and github has this problem. I could write a GM script to append the ? to the end of the url, but I think this is a more general problem that ought to have a general solution.

I generally agree with this. The reason it hasn't happened earlier is that it has potential backwards compatibility issues. We could take the route that Firefox does for XPI installs: site owners must set the proper MIME type. That would have been good long ago, but now could cause big problems, there might be lots of places out there that would break this way.

Thus, black-listing "known bad" values seems the best approach. Any text/html documents are really web pages, almost certainly. The doctype check is also quite interesting.

P.S. Tobbe: Thanks for contributing. If you want to increase the chances that your work is taken and used: always make a potential change in a branch. As far as I understand git/github so far, it's really easy to pull in all the changes made in any branch (like the two you mention above, perhaps) but much harder to pick and choose things not contained in a branch.

Yes, I've made my changes in a branch. The branch contains only those two changes. You should be able to just pull it in.

So what's the status of this now? Do you want my <!DOCTYPE "solution" but just couldn't pull it in cleanly, or do you rather just go with the mime type check? If you do want my patch I'll try to reapply it against the latest code as one commit in a new branch of my fork

I'm not sure.

A) I expect it could be pulled in as is, with manual conflict resolution.
B) I'm (personally) not excited about the way that it will repeatedly bounce the request back and forth, downloading the resource more than once (probably?) and worry about race conditions.

I've still got to think about it a bit, but I'm pretty sure I'll vote for filtering on MIME type,

I agree with this, and also with checking the mime-type and not the actual file.

Well, we've been getting along pretty well without it, but it would be a nice thing to have in a later version after all the other issues / requests are taken care of.

@cedrik

Why not just use a profile location helper and edit the files directly under gmscripts for "development mode"?

This is definitely something I want for GM too, but it will take a while. I don't think it needs a special mode. The fact that the file changed is enough of an indicator. Regular users don't change their user script files.

I think the proposed method of reading metadata directly from the User Script would resolve this issue nicely.

See: http://wiki.github.com/greasemonkey/greasemonkey/ideas-whiteboard

I believe this behavior has no reason to be

I've definitely used this capability to good advantage in the past. The first example I can think of is the script I wrote to scrape your own movie ratings out of Netflix. It works because you're logged in, and can thus access your own pages.

I've been intending to survey how scripts actually use the GM_ apis (including how many actually use the cross-domain abilities of xhr) for some time, but I've hit external snags. I'll try to speed that up, as it would definitely help inform this.

I've definitely used this capability to good advantage in the past.

I'm not sure what exactly you are talking about. Just in case, i'm not criticizing the fact that cookies credentials can be used by GM_xhr, only that all userscripts can access all URI possible without the user's approval.
I fail to see why a userscript would require this capability and, if ever it did, it could always state it explicitly.

XHR cross-domain restrictions are here for a reason. GM_xhr breaks them also for a reason, although the "breach" should remain both explicit and as small as possible.

Edited the title to be more clear, because I keep seeing it and having to re-read it.

I can't disagree with this fundamental idea. I'm just unsure, yet, how to properly implement it. There's definitely some inspiration to be had here:
http://groups.google.com/group/greasemonkey-dev/msg/f3acf7a809365c0a

I think we'd have to do something like listing the host-names that could be connected to. Anything else (if not also this) would be too complex to present to the user, for it to add much in the way of security -- dialogs that users don't read and just click "OK" don't add security.

Eeew. One of the reasons I (and probably many others) love greasemonkey is because of GM_xmlhttpRequest's no-questions-asked-do-as-you-please privilege. The folks at W3C and IETF have great ideas from time to time, but I've never been a fan of the same origin policy. (Somewhat off topic, but I'm just curious, does anyone know how they feel about linking to externally hosted images?). Serious -1 from me on this.

Then again, you guys are super-concerned about security for reasons I have yet to fully understand, because as I currently understand it, it's mainly because you assume the general public is stupid, which is kind of depressing.

If you guys are really going to implement something like this, maybe a one-time question about cross-domain XHR's at greasmonkey's installation would be good enough. Please do not end up doing a ton of questions per script, because a ton of great scripts violate the same origin policy many times during their execution.

As for listing host names, yeah, that sounds good except it would be kind of annoying for you guys to implement and in terms of writing scripts (having to manage a hosts list per script).

I fail to see why a userscript would require this capability

As user "greasemonkey" mentioned, there are tons of scripts which use this feature to fetch external information and bring it to a site. The ones I can think of are torrent sites which can now have an IMDB rating next to the title and a Megaupload script which solves captchas.

Most scripts only "semi-violate" same-origin anyway (sub-domains, or external servers for use with the site). For example, youtube.com uses ytimg.com, and sites like megaupload often use www###.megaupload.

I agree.

As Greasemonkey user, now I use wescript.net for update scripts. It works, but it's another add-on. Not so many people know about it.

Look at Stylish add-on. It has "Find Updates" button Greasemonkey should learn from this.

I see this issue labeled "0.9.x". Great!

GM needs UI for updating scripts.

What do you think about it?

Traditionally, Greasemonkey is used to "fix" a site, wherein the users (rather than the owners/administrators of the site) implement the solution. Setting the "Access-Control" header requires the ability to control and change the server.

Also, of course, GM_xhr is quite a few years older.

-0

I'm suggesting to patch XMLHttpRequest somehow to allow x-domain requests. I'm not suggesting setting "Access-Control" header.

I see. I did not understand your statements.

Since this happened years ago, I don't have an answer for you. I'm pretty confident, however, that it is an accident of history, related to particular design quirks over the lifetime of greasemonkey. Today, it will remain, for backwards compatibility.

I'd love to see an example of what you're talking about with XHR like with log.

Can you produce any evidence that this behavior violates any specifications or documentation in any way? That's how it's supposed to work as far as I know.

I see, according to http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.4 that is how it's supposed to work, even for "HEAD" requests. In that case, would it be possible for GM_xmlhttpRequest to have an option not to follow redirects?

Imo, not that important. Doesn't Firefox just load the cached pages?

Thanks Sam for a detailed ticket however this is "by design". unsafeWindow attempts to access the API are blocked due to JavaScript security vulnerabilities especially from web sites trying to achieve elevated chrome:// privileges.

See also #1019 and a multitude of other dev list discussions.

Probably "invalid" and/or "wontfix" labeling.

Hello Martii,
now it is clear, but I think that it should be noted in this/new releases, since lot of script stopped to work due to this improvement. In this way, a common widely used pattern to get options from the user to be saved in GM scripts (that I - honestly - got from one of dev list discussion about an year ago) is not working anymore. Jjust to be clear, it is not my problem only, since I already have installed scripts of other people working in the same way.
At this point, should not a bad idea to suggest a different pattern to save GM variables via user interaction... ;-)
Anyway, have Happy Holidays and a Happy New Year

I tested this and teramako is correct.

I've patched my clone http://github.com/erikvold/greasemonkey/commit/f579a1e4f8b8b3485077a6ac4b97fc5a94e470ac

E

Same problem here, same GM version.

User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6

Here is a test case userscript: http://userscripts.org/scripts/show/66759

oh I think this might be user error. I thought accelModifiers and accelKeys defined a global hot key, but it appears to just be a way to quickly execute the command while the menu of commands is open, and the accessKey is meant to help a user scroll through a long list of commands.

So you can have multiple commands with the same accessKey, but only one command per accelModifiers + accelKeys combination.

If this is correct then it appears to work for me.

Here are two commits you can cherry pick to address the issues I mention above:
- http://github.com/erikvold/greasemonkey/commit/32401597733e8cf1c3fa847061f47c158f81f0bd - http://github.com/erikvold/greasemonkey/commit/a1d2f380879caa86a47883eb2a0b1f8fbb79b10e

I've written a blog post about some different tests I made while trying to optimize the convert2RegExp function, which you can see here: http://erikvold.com/blog/index.cfm/2010/1/24/greasemonkey-optimization-convert2regexp

At the the moment my clone is using array.push(), but if you read me blog article I found that array.unshift() is waaay faster for FF3.6 and slightly slower for FF3.5..