New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 140 users

Comments by non-members will not trigger notification emails to users who starred this issue.
Status: Fixed
Last visit > 30 days ago
Closed: May 2011
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature

  • Only users with EditIssue permission may comment.

Sign in to add a comment
Support cross-site XMLHttpRequest in content scripts
Reported by, Aug 9 2009 Back to list
Chrome Version       : all
URLs (if applicable) :
Other browsers tested:Firefox
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: no
  Firefox 3.x: 3.5
         IE 7: no
         IE 8: no

request to support all GM functions (Grease Monkey) so that existing 
scripts that work fine in grease moneky in Fire Fox can also work in Google 

right now scripts work but not all GM functions and that should be added... 

What is the expected result?

What happens instead?

Please provide any additional information below. Attach a screenshot if

Comment 2 by, Aug 11 2009
Labels: -Area-Misc Area-Extensions Mstone-X
Status: Available
Summary: Support for GM Functions (Greasemonkey) in Chrome (was: NULL)
Note: the functions that are no implemented include:


We should be able to implement these now that we have sandboxing in place. 
GM_setValue/getValue will be tricky because it requires thinking about what origin 
content scripts are running in.

I think it would be nice if content scripts ran in the extensions origin, but I'm not 
sure how that would interrelate with other web platform features.
Comment 3 by, Aug 11 2009
Is there a description of what these functions do?
Comment 4 by, Aug 11 2009
Sorry, my bad:

GM_xmlhttpRequest is cross-origin XHR.
GM_setvalue/getvalue are per-script (important: not per-domain) storage.

I think it is reasonable to say that we will not support GM_xmlhttpRequest given the 
security issues. However, it's worth thinking about because for content scripts (as 
part of extensions) I think we do eventually want to support cross-origin XHR from 
within a content script.

I don't see a huge problem supporting GM_getValue/GM_setValue, though.
Comment 5 by, Aug 11 2009
BTW, Adam, I wasn't assigning this to you, just thought you'd like to be aware of it.
Comment 6 by, Aug 11 2009
Yeah, I just wanted to understand what's going on.  The XHR seemed clear, but get/setValue were kind of 
mysterious to me.  :)
why cant the GM_xmlhttpRequest
 one be supported.? (just give a big disclaimer on this one? ) since GreaseMonkey
does this fine in FF. 

not trying to be pain... just looking for these feature so I can dump FF... if there
is no way to do this then fine... just figured there might be a way. and also if you
support more GM functions people with existing FF GM scripts wont have to try and
re-write them to function. 
Comment 8 by, Aug 11 2009
The issue at stake is how severe it is if an extension's content script is compromised.  If we allow unfettered 
cross-site XHR from content scripts, then it's quite severe if the content script is compromised.  We would like 
some implementation experience to see how often content scripts are vulnerable to compromise in the wild.
understandable.... I see your comments on GM_setvalue/getvalue was curious if you think 
these commands would be possible for the future? thanks again for the great work on the 
Would like the GM_openInTab implemented to go around an intranet javascript heavy site that opens new windows just about 
everywhere. Sorry for cross-reference, but issue ID 20738 raised to have it work like Firefox 3.5+ instead of going around 
the problem. No more new windows.
Comment 11 by, Sep 8 2009
@abarth Regarding GM_xmlhttpRequest, is it possible to implement a whitelist of allowed 
XHR scripts? The AJAX libraries hosted by Google would be a nice start.
You should feel free to include those AJAX libraries in your extension as a content script.  They'll happily run.  :)
Comment 13 Deleted
Comment 14 by Deleted ...@, Sep 23 2009
Add support to "unsafeWindow" is the most important thing since there isn't any other
way (if I'm wrong correct me) to make a function visible to the site (also append to
the window object don't work).
We're not going to support unsafeWindow.  It is unsafe.  :)
Comment 16 by Deleted ...@, Sep 23 2009
Everything is unsafe, really :)
I'm not really interested in unsafeWindow, I only need a way to make a function 
visible to the page (without that thing, the support for "User Scripts" is entirely 
Comment 17 by, Sep 23 2009
ale5000: You're right. The ~93% of scripts on that don't use 
unsafeWindow are entirely pointless.
not supporting unsafe ! :(
The place I work at has "remedy" for ticket issues etc. If you know of it, you are
aware that every "ticket" you open/save/update generates some random JS error that
does not appear in IE6. Only way to get rid of it in Firefox is using unsafe script

@nicholasdrouin: If you'd like to alter the page's JavaScript objects, you can insert a <script> tag into the page 
and run whatever script you like.  Alternatively, you can navigate the page to a JavaScript URL.

@aa: Maybe we should expose an API that makes it easy to eval a script in the page's context?
Comment 20 Deleted
Comment 21 by, Sep 23 2009
@abarth: Yeah, I'd love to see suggestions. See also:  bug 22103 . I'm really keen on 
that one (already started working on it on the side).

This is going to be a balancing act. On one side, you have a gun so hard to use that 
people shoot themselves in the face trying to get it to work. On the other, you have 
one so easy to use it goes off accidentally and they shoot themselves in the foot.

(Edit: wordsmithing)
Well, my current userscript for unsafe is just this one liner to just completely ignore 
the pop up:
unsafeWindow.alert = function alert(message) {return true;};

That was the only why I found that works. Open to an alternative if it fixes the 
problem without unasfe :D
Ah, that case is easy.  Give the below a try:

window.location = "javascript:window.alert = function alert(message) {return true;}; void(0);";

Comment 24 by Deleted ...@, Sep 23 2009
@abarth: It work fine for single line functions but when you have a much complicate
I'm trying to do a script that work on Google Chrome, Opera, Firefox and Safari,
without unsafeWindow is a nightmare.
You can put as complicated a thing as you like into a JavaScript URL.  I might be mistaken, but I'd be surprised if 
Safari as an unsafeWindow API.  The simplest thing is probably to inject a script tag with a src attribute that pulls 
in the script from your server.

Comment 26 by Deleted ...@, Sep 23 2009
I use code like this:
window.test = function(){alert("it is a test function");};
if(typeof unsafeWindow == "object") unsafeWindow.window.test = window.test;

In Opera it work directly instead in Firefox it use unsafeWindow.
I need a hack that don't involve changing the code completely.
Why not just make a script tag that has that contents and inject that script tag into the document?

function evalScriptInPage(yourScriptHere) {
  var elmt = document.createElement("script");
  elmt.textContent = yourScriptHere;

evalScriptInPage('window.test = function(){alert("it is a test function");};');

In any case, this seems like a solvable engineering problem.  We're not going to introduce a security vulnerability 
in the extension system to make this easier.

Comment 28 by Deleted ...@, Sep 23 2009
Probably that can be done but only for scripts that aren't complicate, because this
will clutter too much.
What security vulnerability causes "unsafeWindow" exactly? (All other browsers have a
way to do these things)
If you're interested in the security issues, you might be interested in these papers, which describe some of the 
issues (albeit in a slightly different setting):

Thanks a lot As you can tell, I am not a javascript expert.
That fixed by issue without unsafe :D
Comment 31 by Deleted ...@, Nov 16 2009
unsafeWindow indeed is useful in the 99% of scripts that do not store important user 
data across multiple domains. Given that you already ruled out GM_xmlhttpRequest, 
what harm could come from exposing the GM script's privates to the web site? The 
GreaseMonkey script has no more privileges than the origin site.

In Opera and Safari, user scripts run in the same namespace as the site itself 
(equivalent to doing everything through unsafeWindow) and there is no problem with 

@marti, From a security point of view, we could offer a way to run content scripts
entirely within the page's context (i.e., in the unsafeWindow).  The trade-off would
be that they won't have access to the chrome.* APIs.  I'm not sure if aa wants to do
that from an API design point of view, but you're right that it would be ok from a
security point of view.
Comment 33 by, Nov 16 2009
It's still on the table from an API point of view.
Comment 34 by, Nov 16 2009
Labels: Feature-Extensions
Comment 35 by Deleted ...@, Nov 17 2009
@abarth: You mean like Greasemonkey's @unwrap directive? Sure, that would be nice. I
wasn't aware that user scripts currently have access to internal Chrome APIs.

About @unwrap see

Comment 36 by, Nov 19 2009
Labels: -Area-Extensions
Comment 37 by, Nov 26 2009
GM_xmlhttpRequest (i.e. cross-origin XHR) is required for *user* scripts. Hey, guys.
This is USER script so there is no point to limit it to the same origin, because the
script is installed on user's demand (and he have to click the button in the annoy
@KJackie: These issues are subtle. We need more implementation experience to see
whether folks are able to write secure user scripts in practice.  If a large
percentage of the content scripts can be compromised by the page, then we need to be
very careful about giving them more privileges.  If people tend to write secure user
scripts by and large, then we'll be more comfortable implementing GM_xmlhttpRequest.
Comment 39 by, Nov 26 2009
What's wrong with using as a "implementation experience"? Sure, they 
don't all work directly on Chrome, but that doesn't matter. They give you a very good 
idea of what user scripts are used for and how serious privilege abuse can be.
Comment 40 by, Nov 26 2009
@igitur: We already know what user scripts are used for and how serious problems can be 
(very, that is the reason we're being careful).

It's an interesting idea to look at the top xx user scripts on and 
imagine if they were implemented in Chrome exactly as-is, if they'd be exploitable.
Labels: -Mstone-X Mstone-5
Status: Assigned
I've been looking at the content scripts in the gallery and I'm getting more
confident that we can expose cross-site XMLHttpRequest in the isolated world. 
Assigned for investigation.
Comment 42 by Deleted ...@, Dec 17 2009
Can you tell me some examples of unsafe XHR ? :)

If I want to do some hacking, I better use PHP+sockets.
Comment 43 by, Dec 17 2009
How your PHP+sockets works? You setup a server and it works like a proxy? Or you hack
the server of google, yahoo, or facebook?

In my personal use case is sending something useful to my personal server from random
websites (push). But some people may use cross-origin XHR to reference other similar
 informations from other websites (pull).
Comment 44 by Deleted ...@, Dec 17 2009
IMHO, where GreaseMonkey went wrong was exposing security-sensitive APIs like 
GM_xmlhttpRequest by default, with no way to abstain from it. *That's* why 
GreaseMonkey scripts have security issues, NOT because it allows the usage of 

So I believe user scripts should contain yet another attribute that specifies which 
APIs it actually wants access to (such as cross-site GM_xmlhttpRequest, unsafeWindow,, script storage). A script is potentially insecure only if it requests 
both unsafeWindow *and* cross-site XHR.

Another idea: I think script storage should be implemented through the HTML5 web 
storage interface and GM_getValue/GM_setValue can be thin wrappers around that. That 
way there's also a familiar and standardized interface.

Are these ideas workable? Does this make sense to anyone else too?

Comment 45 by Deleted ...@, Dec 17 2009
> How your PHP+sockets works?
It was example. I mean, if I want to do some XHR, I will find the workaround anyway.
Why I must use dirty tricks like IFRAME e.g., when I have more convenient way by Ajax?
Can someone tell me?
There are thousands of scripts on, and I have yet to see a site
maliciously write JavaScript to counteract a userscript.

For example, using unsafeWindow on YouTube (which is incredibly useful) won't cause
any problems, unless Google has abandoned all reason and went against their "Don't be
evil" motto.

I've posted a message a day ago in the chrome extensions discussions and it still
hasn't shown up. Basically, I wanted to know if we can get some sort of
permissions-based system where we request usage of the various "dangerous" API's. If
a "dangerous" API is being used, an extension can be flagged as dangerous, and users
who are installing them would be warned about the potential security risks.

I'm sure there are other scripters who don't mind the "risk", as well as the users of
the scripts who would be bold enough to install regardless of the warnings.
aavindraa is right. I don't think there has ever been a reported case of a site 
specifically writing JavaScript in an attempt to hijack Greasemonkey API functions. It 
is just a hypothetical scenario that the devs of Greasemonkey have tried to prevent 

The only API that has any real danger to it being hijacked by a web site is cross-
domain XHR via GM_xmlhttprequest. Because cookies are passed along in these 
requests just as if the user was making these requests themselves, a site that has 
gained access to GM_xmlhttprequest could take actions on a user's behalf (e.g., 
submitting false posts, getting access to pages with sensitive information). One way 
to prevent these nefarious actions would be to strip cookie data from cross-domain 
XHR. This would put some limitations on functionality, but maybe if some type of 
sandbox is used (similar to one in Greasemonkey), we could just strip cookies from 
cross-domain XHR that is initiated from outside the sandbox (i.e. unsafeWindow).
Comment 48 by, Dec 20 2009
It seems the web sites can't use GM_xmlhttprequest() in current version of
Greasemonkey, so it is impossible to hijack it unless the (user) script writer let it
do. Chrome also has "isolate" feature in user scripts, so I think is isn't so dangerous.
Security is a tricky business.  It's not enough to defend against attacks that are
already taking placing in the world.  You need to plan ahead and avoid opening up
vulnerabilities that attackers can exploit later.  We don't want to paint ourselves
into a corner where we can't respond to security problems.

Providing access to unsafeWindow is something that can't be made safe, and therefore
we're not going to implement it.  We can make cross-site XMLHttpRequest safe, so we
are going to provide it.  If you have a proposal for how we can implement
unsafeWindow safely, I'd love to hear it.
Comment 50 Deleted
Comment 51 Deleted
Currently Greasemonkey attempts to prevent access of the GM api functions by the
javascript of a page by checking the call stack. One way to subvert this measure is
by calling the GM api functions through a setTimeout, so this method of validation is
not bulletproof.

"If you have a proposal for how we can implement
unsafeWindow safely"

How about my suggestion of stripping cookies from cross-site XHR or perhaps only
allowing cookies to be set manually (meaning that browser cookies that are already
set will not be passed automatically)? Wouldn't this ensure that a page could not act
on behalf of a user by gaining access to cross-site XHR through unsafeWindow?

Comment 53 by, Dec 20 2009
@medleymind: Web servers can make auth decisions based on more than just cookies. For 
example, lots of corporate intranets make them based on the client ip address. 
Stripping cookies would only help protect those servers that use cookies.
@medleymind: You might be interested in the XDomainRequest and CORS APIs.  Notice
that those APIs require the server to opt-in by sending back a certain header, even
when cookies aren't involved.
In general, the danger of cross-site XHR being exploited by malicious javascript is
gaining access to secure information. A web server that bases its authorization on
client ip address is hardly secure. While there are other methods used for auth
decisions, cookies are still the core mechanism for most web services.

I do not see the relevance of cross-origin resource sharing.
Comment 56 Deleted
Anyway, if you deem that cross-site XHR and unsafeWindow cannot safely coexist, I
consider cross-site XHR a much more valuable resource.

Re: unsafeWindow

What if you adapted a similar approach to window.postMessage?
"window.postMessage is a method for safely enabling cross-origin communication."

I was thinking you could do something like this:
1.It happens before the script runs...
2.Since everything in javascript is an object, save every "object" on the webpage to
an associative array (e.g. var webPageObjects={})
3.Use JSON to convert them all to a string (JSON.stringify(webPageObjects))
4.Send the string from the webpage "space" to the privelaged extension "space".
(pseudocode: chrome.postMessage(string,extensionID))
5.The script extension "space" now uses JSON.parse() to parse the string message and
the script/extension now has access to variable names/values, functions etc that were
on the webpage.
Note: not "live" access.

I have no idea if this is actually feasable, it's just an idea I had. :

I was thinking at first I'd have to parse objects using RegEx and some constructors
from <script> tags, or god forbid, do an XMLHttpRequest to <script>'s with "src's",
hence double-fetching information. But I guess we can store information in a JSON
object and put it as a string in say, the "title" of an element. Since this is
visible to both "worlds", the other side can JSON.parse it up.

I don't know how feasible this is, and it's definitely double-work regardless. I'll
try it out, if there aren't too many problems then I wouldn't care too much about
direct access to the page.
Comment 60 by Deleted ...@, Dec 20 2009
@ abarth
> Providing access to unsafeWindow is something that can't be made safe, and
> therefore we're not going to implement it.

What you mean with "safe"? Even if a website can execute code in the script's
sandbox, what's inherently unsafe about that? The ONLY privilege that the script has
over the website's JavaScript would be cross-site XHR. If the script could somehow
abstain from that privilege, then there would be nothing to be gained from breaking
into the sandbox.

Most users trust the script less than they trust the websites they are using it on.
Giving every script the privilege to do cross-site XHRs is a security nightmare
regardless of whether unsafeWindow is there or not.

aavindraa's solution, where a script clearly declares the APIs it needs to use,
solves all of this.

1) Currently, the main additional privilege a content script has over the page itself
is the ability to use the chrome.* APIs to talk to the background page.

2) We might want to give content scripts additional privileges in the future (e.g.,
the ability to open pop-ups without a user gesture, cross-site XMLHttpRequest, etc).
 If we give up on isolating the content script from the page now, we'll foreclose
this opportunity.

3) Even with zero additional privileges, letting the page compromise the content
script leads to security problem.  This paper
<> contains a detailed
explanation of how a number of bookmarklets (which are like non-isolated content
scripts) let a malicious web site steal all the user's passwords.

We want to protect the content script from the page, both because of the privileges
the content script has today and because of the privileges we might give content
scripts in the future.  unsafeWindow and friends do not provide a sufficient level of
protection, therefore we're not going to implement them.

Given our experience looking at extensions people are writing, it the benefit of
adding cross-site XMLHttpRequest (limited, of course, by the manifest) to content
scripts appears to out-weigh the security costs.  That's a judgment call, but Aaron
and I agree its worth it, and that's what they pay us the big bucks to do.

I'm glad you all are interested in these questions.  If you read this bug from the
beginning, you'll see that we're listening to your feedback and we've changed our
plans based on the information presented in this thread.  It's possible we'll
consider implementing unsafeWindow in the future, but we want to evolve the extension
platform slowly and carefully.  At this time, unsafeWindow looks like a bad set of
trade-offs.  Hopefully we can find a safe way of address the same use cases.
Are you sure you just can't check the call stack of the API functions to make sure the 
page's javascript didn't call them the way Greasemonkey does it through 
Comment 63 by, Dec 21 2009
FYI, GM_apiLeakCheck does not work well. The current Greasemonkey maintainers are 
trying to find a way to remove it because it has lots of false positives, where it 
incorrectly prevents you from using the API.
The false positives of GM_apiLeakCheck come from the way Firefox handles events and 
because GM_apiLeakCheck is implement in Javascript it is more difficult to find a work-
around. Surely you could work out the problems easier if you implement it in native 
Comment 65 by, Dec 21 2009
Everyone: I think it's time to take this discussion to the mailing list. I've continued it 
Comment 66 Deleted
"I tried to post there, but my reply isn't showing up so I have no choice but to post

Same. I posted there about this + regular expression matching for content scripts,
but neither post showed up. :(
Comment 68 by, Dec 21 2009
@aavindraa & @medleymind - did you subscribe to the group, first?
I joined, and chose "No Email (I will read this group on the web)". Is joining the
same as subscribing?
Comment 70 by, Dec 21 2009
Yes. You joined before you posted, right? and you have posted from the group page, not 
your e-mail, right?
Comment 71 Deleted
Sometimes posts can take a while to show up in google groups. Especially if you've
just joined the group.

That's been my observation anyway.
Summary: Support cross-site XMLHttpRequest in content scripts (was: NULL)
Labels: Area-Feature
I believe cross-site XMLHttpRequests are already possible, as long as the target
server returns appropriate response headers.

From  bug 24492  :

"requests can be cross-domain with the Access Control spec
thanks, I didn't know about that Access-Control-Allow-Origin

can anyone confirm if chrome supports it?
If you have access to the server, why would you be writing a userscript?
Yes, we do support Access-Control-Allow-Origin.

Sorry this bug is taking a while.  I keep getting higher priority items added to my
queue.  :(
Labels: -Area-Feature Area-UI
This is at-risk for Mstone-5 unless I stop getting interrupts.
Comment 82 by, Mar 8 2010
Does not block mstone-5 (sorry everyone!).
Comment 83 by, Mar 9 2010
Labels: -Mstone-5
let me know when this is avail I would love to test it with the internal work scripts
that we use here at Cisco. (right now I use FF because of the scripts not working)
You can work around the lack of this feature by sending a message to the background
page.  You can see an example here:
True, but would be nice to avoid bouncing messages from/to the background page at least 
in this case, we are already doing this a lot ...
Comment 87 by Deleted ...@, Mar 11 2010
What if you allow scripts to set who they want to communicate to in the header?


with same syntax as the match header
Comment 88 by, Mar 23 2010
whats the status?
Comment 89 by, Mar 23 2010
Look at the top left: 

Status: 	Assigned
I think he meant to ask do you know what nightlight build will have this? (and or dev
Comment 91 by, Mar 26 2010
lol @ igitur

yes, the development status (alpha, beta, won't think about, we somehow started, doing 
it slowly, etc)
Comment 92 by, Mar 26 2010
I would just like to add that I am also eagerly awaiting the implementation of 
GM_xmlhttprequest for XSS in User Scripts. :)
This bug is not targeted at any particular milestone, I've been working on higher
priority items.
I ditched Firefox about day 1 when Chrome came out - I've had to re-open it JUST to get 
this damn functionality.  (Ok that's not true I still use it for Firebug).  

However, PLEASE look at some way of giving us cross domain XHR at some point, I find it 
very useful for my personal scripting and automating tasks for users/friends/family.  
So just adding +1 vote for it here, since I was googling to find out if there was 
anyway to get Chrome to work more like a true Greasemonkey script here.  PS I love 
chrome, just wanted to say that too.
Comment 95 by, Mar 27 2010
I can't understand, at the moment, how implementing these 13 functions can be so 
hard,  chromium being a full flagged browser.
Greasemonkey itself is open source, what is the matter?

what makes chrome coders ignore the potential overkill of users moving to chrome, 
because all their scripts work on chrome? userscripts got thousands of downloads per 
minute, think about it
95, it's not about the difficulty of implementing it, it's about the difficulty of implementing it safely. Cross-site 
requests are a huge security issue.

I personally think it'd be sufficient to just ask users if they want to allow scripts to perform a cross-site request 
the first time the script does it, but the developers don't seem to think there's an acceptable way to do it. I might 
even dive into this sometime soon.
@caesar2k: Patches welcome.  Implementing this feature is more subtle than you might
After scanning down the comments I'm still a bit unclear on whether this is being
implemented. If not, would like to add my small, insignificant voice to those who are
really pining for it. Some of Greasemonkey's most powerful scripts use the cross-site
go-getting functionality, it adds a whole new layer of possibilities such as doing
all sorts of lookups etc. that would be impossible without. As for the security
argument I'd just like to hear one example of a person whose life has been made to
suffer by this being available in Firefox... OK maybe such a person can be found
somewhere but I'm guessing there must be millions(?) who are slightly suffering when
using Chrome for the excellent speed + interface it provides but not being able to
install their favourite scripts. Cheers, Steve
Comment 99 by Deleted ...@, May 27 2010
This one feature stops me from migrating to chrome from firefox.
Definitely one of the big reasons why I still use Firefox.
GM_setValue and GM_getValue also seems to live a life of their own over at  Issue 33089  - just to make sure everyone's aware of that one :) A lot of userscripts make use of those calls without needing cross-site XHR.
Comment 102 by Deleted ...@, Jun 30 2010
My script *only* works because GHXR is cros-domain. If its safe enough for Firefox (and presumably Opera?), then its safe enough for Chromium, I would think:
Agree with the last several posts - GM_XHR cross-site policy is the only reason I use FF at all.  Can't do my data mashups without it, and those mashups save me innumerable hours a day of wasted lookup time.

At least the Dev Console is competitive with Firebug - a bit of a learning curve and some subtle differences, but competitive.

You could always try to make an extension with permissions to those sites (or every site) and load them communicating the background webpage with the content script, which seems to work quiet well
The problem is that there are already userscripts using GM_XHR, and it seems unnecessary effort to rewrite them as Chrome extensions. By the way, what is the security advantage of Chrome extension over userscripts on this topic? For the following reasons I think userscripts can be at least as secure as extensions when they are allowed to make cross domain requests:

Extensions need to declare the hosts they want to access cross-domain, and users are warned about them when installing them. But: 1) users interested in the functionality often click ahead, and rarely check what the extension really does when accessing other hosts, 2) as ratchet.freak suggested, the same kind of restrction can be placed on userscripts too.

Both extensions and user scripts require users to explicitly install, but userscripts tend to be smaller and its source is easily viewable, while extensions are typically installed without users examining the source first, and  may be auto-updated (although updates may improve security, they may introduce holes without the user knowing too).
Comment 106 by, Sep 15 2010
Labels: -Type-Bug Type-Feature Mstone-X
Reclassifying as feature. This has no impact on priority, I'm just cleaning up the bugs db.
So, is XHR going to work in userscripts or what?
Doing this right might be complicated, so how about taking a first step and adding a command line flag that enables GM_XHR in all its (unsafe) glory; as a first step it could even go without asking for permissions to the specific sites the userscript declares. This would surely make the next step, asking on specific permissions, easier to get going. (Hint: It might be possible to recruit C++ skilled people from some GreaseMonkey community or maillist.)
Why can't a userscript just act like a native extension and tell the person installing it what sites this particular script is going to access?
I thought maybe there could be some additional metadata added to the script to ask for permissions for XHR or something.. 
I'm haven't seen the source of chromium, but i'm pretty sure this shouldn't be hard to do.. after all, it has already been implemented for native extensions.
As many others, i wont migrate to chrome since I can't install Smart Google Subscriber or Twitter Follow Helper, which are some most useful hacks i'm using...
It's so bad since Chromium is very well designed for use in Jolicloud...
Comment 111 by, Nov 11 2010
It isn't a security issue; we've already agreed that we can do this and would like to do this. It's simply a resource issue -- we haven't yet had the time to.

It's definitely near the top of the pile of features we'd like to implement.
Comment 112 Deleted
Comment 113 by Deleted ...@, Feb 24 2011
Has this feature gone from near the top to the top yet? :)
Cc: a deleted user
Labels: -Mstone-X Mstone-13
Owner: a deleted user
Status: Started
I talked to Adam about this, and the rough plan is to add ScriptExecutionContext::getSecurityOrigin(DOMWrapperWorld*) which mirrors Document::getWrapperCache(DOMWrapperWorld* world) (which allows per-isolated world DOM wrappers). Then we can have a per-isolated world list of additional origins that are whitelisted for access.

This involves fleshing out the V8 side of DOMWrapperWorld, which right now is basically a stub, since the V8 isolated worlds are tracked differently (via a V8IsolatedContext pointer that is stashed on the DOMWindow). Switching to worlds outliving windows will also allow us to fix  bug 20773  (content scripts can't see into iframes).

This will also require that content script injection switch to the same codepath as Safari (PageGroup::addUserScriptToWorld) instead of the v8-only ScriptController::evaluateInIsolatedWorld.

The plus side of all that is that we'll be closer to the Safari/JSC implementation, which means better coverage via layout tests, etc.

Adam, please let me know if I've misunderstood anything.
> Adam, please let me know if I've misunderstood anything.

Sounds right.  It might be worth chatting with Sam on #webkit about the change to ScriptExecutionContext::getSecurityOrigin.

It occurred to me, by the way, that there's another possible approach that requires less refactoring of the known universe: we can pass the appropriate securityOrigin object to the XMLHttpRequest object when it's constructed (via the bindings) instead of getting it from the ScriptExecutionContext later.  There are trade-offs, of course, but I thought I should mention it.
> we can pass the appropriate securityOrigin object to the XMLHttpRequest
> object when it's constructed (via the bindings)

The trade-off with that is that there are a bunch of other places that get the SecurityOrigin via document->securityOrigin() (e.g. DocumentThreadableLoader, which XMLHttpRequest uses), so I'm worried about getting inconsistent responses if we don't pass it around to all the right places.
Actually, I'm going to try the SecurityOrigin-passed-to-XHR-constructor approach, since as you said, attaching the SecurityOrigin to DOMWrapperWorld and then needing to pass the world everywhere needs too much refactoring.
Status: ExternalDependency
Started to work on the WebKit side of this at
Labels: TaskForce-BackgroundPagesMustDie
Status: Started
WebKit side has landed as Working on the Chromium side of the patch now.
Project Member Comment 123 by, May 27 2011
The following revision refers to this bug:

r87114 | | Fri May 27 16:45:31 PDT 2011

Changed paths:
 A (from /trunk/src/chrome/test/data/extensions/api_test/cross_origin_xhr/manifest.json revision 86895)
 A (from /trunk/src/chrome/test/data/extensions/api_test/cross_origin_xhr/test.html revision 86895)
 A (from /trunk/src/chrome/test/data/extensions/api_test/cross_origin_xhr/manifest.json revision 86895)

Use WebFrame::setIsolatedWorldSecurityOrigin to allow cross-origin XHRs in content scripts. adds the ability to associated a security origin with
an isolated world. Use that to make content script isolated worlds use the extension's
origin, and whitelist that origin in the page's renderer process for the host permissions
in the manifest.

BUG= 18857 

Review URL:
Status: Fixed
This is now implemented and should be in the current Canary channel builds (13.0.781) and in the next dev channel release. If you starred or commented on this bug wanting this capability, please try it out. If there any issues with the current implementation, please file new bugs about them.
Hi, I'm trying using 17.0.933.1 canary but when I use an user script with a GM_XMLHttpRequest call I get this:

XMLHttpRequest cannot load [different URL than origin]. Origin chrome-extension://djcdaodcljgbfghhppbalfoldkdjgebb is not allowed by Access-Control-Allow-Origin.

where [different URL than origin] is the url I'm trying to get data from.
Has it been disabled again?
a quick workaround is --disable-web-security
Comment 127 by, Nov 11 2011
#125, 126: I do not reproduce this @109194 on trunk. Do either of you have a sample extension that doesn't work as you expect?
Here's an example that uses XMLHttpRequest that works fine in Firefox, but fails in Chrome:

Using the Developer Tools, it appears that the xml request starts, but the preview and response are empty.
Comment 129 by, Nov 11 2011
#128: It looks like there is a bug in developer tools where the response is not shown when the string is very long. But the response is there.

I see another error in the script:

That is why the script probably isn't working. Looks like some difference in XML support between Firefox and Chrome.
Aaron is right. If you switch from getElementsByTagName('gxs:url') to getElementsByTagNameNS('', 'url') (and the same for 'gsx:scrore') then things work as expected.
Great, thanks. That worked perfectly.
Why is this marked as closed when setValue, getValue and deleteValue are not supported?
rssallan3: Support for GM_setValue, etc. is being tracked in 33089, this bug was about cross-origin XMLHttpRequest only.
Project Member Comment 134 by, Oct 13 2012
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 135 by, Mar 10 2013
Labels: -Feature-Extensions -Area-UI -Mstone-13 Cr-Platform-Extensions Cr-UI M-13
Project Member Comment 136 by, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member Comment 137 by, May 23 2013
Project: chromeos/vendor/mali-ddk
Branch : wk45-2012
Author : Gabriele Paoloni <>
Commit : 8cd420d0a7e502051236b8edeef83737956a47ec

Code Review  +2: John Sheu, Stéphane Marchesin
Verified     +1: John Sheu, Stéphane Marchesin
Commit Ready   : Stéphane Marchesin
Change-Id      : I6286735a9cae965554f4fe66028dac62591d57f0
Reviewed-at    :

CHROMIUM: fix "eglClientWaitSync does not barrier external texture reads"

Now we wait on the force_fragment_order global event when creating a sync.
This workaround seems to fix the issue

BUG= chromium:18857 
TEST=tested on Snow board

Signed-off-by: Gabriele Paoloni <>
Commit-Queue: Stéphane Marchesin <>

M  cframe/src/mali_cframe_dependency.c
M  cframe/src/mali_cframe_public_declarations.h
M  gles/src/sync/mali_gles_sync_module_api.c
Project Member Comment 138 by, May 24 2013
Labels: Mstone-28
Project: chromeos/vendor/mali-ddk
Branch : release-R28-4100.B
Author : Gabriele Paoloni <>
Commit : 3f57fc5060f52c5bdbc874efe7b6176930b98412

Code Review +2: John Sheu
Verified    +1: John Sheu
Change-Id     : I6286735a9cae965554f4fe66028dac62591d57f0
Reviewed-at   :

CHROMIUM: fix "eglClientWaitSync does not barrier external texture reads"

Now we wait on the force_fragment_order global event when creating a sync.
This workaround seems to fix the issue

BUG= chromium:18857 
TEST=tested on Snow board

Signed-off-by: Gabriele Paoloni <>
Commit-Queue: John Sheu <>

M  cframe/src/mali_cframe_dependency.c
M  cframe/src/mali_cframe_public_declarations.h
M  gles/src/sync/mali_gles_sync_module_api.c
Sign in to add a comment