GM_xmlhttpRequest tripping GM security functions? Maybe not the same as years-old issue? #1674

merricksdad opened this Issue Dec 4, 2012 · 5 comments


None yet
2 participants

GM 1.4 and GM 1.5 tested
FF 17 and 17.0.1 tested

Error shown:
Greasemonkey access violation: unsafeWindow cannot call GM_xmlhttpRequest

also occasionally

Greasemonkey access violation: unsafeWindow cannot call GM_setValue

I have a script that uses a bunch of GM_xmlhttpRequest calls. They worked wonderfully until recently. Now I have the first error about 6 out of 10 times I start my script, however, the other 4 out of 10 times, the script and all its cross-domain requests work just fine.

I am NOT using unsafeWindow, nor do I @grant unsafe window in my script header.

The request is called through a chain of events started at a DOM element click, so I feel that the initial source object for the event is that DOM element. I am just a little confused as to why it would register as being associated with unsafeWindow, rather than the true window object in some instances but not others. Beyond the scope of the userscript, a secondary user script is actually using a setTimeout to do the clicking on an element created by the primary script.

Here's a diagram showing the path of events:

*Script A creates a DOM element on a page (no particular page is required) and gives that element an onclick function
*Script B creates another DOM element and attaches it to the DOM element created by script A
*Script B then sets a timeout and programatically clicks the DOM element created by script A
*Script A then takes the DOM element added by Script B and reads a huge quantity of data from it
*Script A then acts on that data and begins a series of cross-domain requests

I use the common scripted mouse-click to do my clicking from Script B to Script A's element. "... .ownerDocument.createEvent('MouseEvents').initMouseEvent('click' ..."

I've lightly read up on previous posts referencing this error, but am not sure this is the same issue. Again I am not using unsafeWindow, nor is the secondary script. Both scripts are in sandboxes, not in page-land. Script A specifically uses @grant statements to fill in its API needs. Script B does not.

I'm trying to track down something I don't fully understand, so here are my uneducated thoughts:

At some point during user script loading, the differences between window and unsafeWindow are not clear. When my script fires just fine 4 out of 10 times, it makes me also wonder if this is timing related. Both scripts are firing off as much stuff as possible in the shortest amount of time, using a timeout of 1 second in only one process in the chain (the click). Other sections are using tight FOR loops, but do not seem suspect.

Here's a list of the scripts used to produce this error:

(As Script A)
FB Wall Manager 3 Beta 9 --

(As Script B)
CafeWorld Sidekick --
FarmVille Sidekick --
PioneerTrail Sidekick --

A facebook account is required to test the scripts
You must be logged into facebook to test successfully
Visit page to test:

I've disabled all other scripts except these without any change
I've tried combinations with sidekicks removed without any change
With firebug enabled/disabled there is no change
I do have a few other extensions: AdBlock, MemoryFox, FlashBlock

Another issue is that the error seems to not be captured by the GM_xmlhttpRequest onerror parameter. Instead it goes directly to the javascript console, even though the request is also wrapped in a try/catch to log the error elsewhere.

Any help is much appreciated, so thank you in advance.

Separating the event chain into two parts, I was able to force the requests to be spawned by script A rather than script B and this fixed the issue entirely. However, that does not explain the intermittent nature of the issue when script B was the source of the event chain. Why would the majority of instances NOT allow script B to be the source of the event chain eventually calling the request, yet a good percent of the time it can be allowed?


arantius commented Dec 4, 2012

I know you claim that it worked before, but:

*Script B then sets a timeout and programatically clicks the DOM element created by script A

Sounds a lot like #1001. Script B with no grants should be running in the page.

Have you tried the workaround listed here?

I thought so at first too, and I suspect they are related, but then why does it work sometimes and not others? If you care to try them, hop back to version 3.0b9 of the WM host script and use the current versions of the others and see for yourself. Smack the refresh button around a bit and see how many misfires to unhindered runs you get. Mine runs very randomly, but small tests are about 6 fail to 4 good.

No, I didn't try the fakeTimeout. I felt that in the sequence of events, even fakeTimeout being called to make a click spawned at Script B would fall under the same security rules catching my click function spawned from a sandboxed setTimeout in Script B. Do you feel that it would not be the case? The timeout I would replace is in script B, so fakeTimeout should be caught too, right (if that script B occasionally strays across the page/script boundary)? If I make a function to pass in the callback value, and that function is made within script B...perhaps I fail to understand what is and is not inspected before its allowed to access the listed API's.

I double checked your belief that "Script B with no grants should be running in the page" and found that one script did not have any automatically detected grants stored in the config.xml file under gm_scripts. I now believe that must be the culprit. All other varieties of script B have a @require'd library containing parts that should be caught by the grant autodetect, and they register accurately. But again that does not explain the intermittent full functioning of that one odd script B, specifically the FV Sidekick (


arantius commented Dec 20, 2012

If you can isolate this to a standalone testcase, I might be able to work on this enough to figure it out. But I can't see debugging multiple many-thousand line scripts, especially on Facebook.

Entirely understandable. From my angle its really not worth looking into further just for one sidekick.

At least its not as bad as the crazy leak I spotted in google-chrome when used with tampermonkey and GM_setvalue/getvalue at high speed in multiple scripts on the same page.


arantius commented Jan 24, 2013

Will fix if I get a reduced test case. Otherwise, WFM.

@arantius arantius closed this Jul 9, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment