Re: Accessing @mozilla.org/xmlextras/xmlhttprequest;1 from content
On Monday, February 25, 2013 9:45:35 AM UTC+1, mat...@salsitasoft.com wrote: > Changing back to chrome:// URLs solves all of this (including eliminating the > need to muck with the XHR implementation in the background page) except the > original problem of accessing them via XHR in the sandbox. But using the > system principal in the sandbox appears to fix this (thanks Brian!). BTW: Using the system principal for my sandbox lets me use the privileged XHR implementation in FF19+. However, this seems to break the code in FF<=18 (where I used a chrome window as the principal for the sandbox). I'd like to preserve backwards compatibility at least for a version or two. For now I'll use nsIXULAppInfo to check the version, but if there's a way to check the capability directly I'd prefer that. Can anyone point me to the bug where this behavior was changed? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Accessing @mozilla.org/xmlextras/xmlhttprequest;1 from content
On Monday, February 25, 2013 4:27:24 AM UTC+1, Boris Zbarsky wrote: > The DOM returned by responseXML is associated with the origin the XHR > was initialized with. > > As far as how you set this origin, it used to be that you could do this > directly from a component, but now it looks like we always use the > principal of the associated window, if any. > > Unfortunately, we also use that window to determine whether this is a > system XHR or not, as far as I can tell... I'm not going to need to deal with this for this rev (hopefully) but very useful info nonetheless. Thanks! Matt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Accessing @mozilla.org/xmlextras/xmlhttprequest;1 from content
On Monday, February 25, 2013 4:27:24 AM UTC+1, Boris Zbarsky wrote: > > I guess the reason I'm suddenly having this problem is > > https://bugzilla.mozilla.org/show_bug.cgi?id=809652 > > Seems pretty unlikely. Yes, I misanalyzed this. It appears that the root cause of the problem was that my content scripts (which run in a sandbox) stopped being able to request chrome:// URLs in FF19. I therefore changed to resource:// URLs. Apparently DOMWindowCreated doesn't fire for a resource:// URL in a browser with type == "chrome", so this is indeed not a FF19 change. This led me to use type == "content" (in retrospect a bad idea) and inject my own XHR implementation. Changing back to chrome:// URLs solves all of this (including eliminating the need to muck with the XHR implementation in the background page) except the original problem of accessing them via XHR in the sandbox. But using the system principal in the sandbox appears to fix this (thanks Brian!). Hopefully I'm all good now with respect to FF19. Thanks for the help. Matt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Accessing @mozilla.org/xmlextras/xmlhttprequest;1 from content
On 2/23/13 1:08 PM, matt...@salsitasoft.com wrote: Currently I have to admit that I don't understand how the code addresses the issue of giving content access to the responseXML DOM returned by the Cc['@mozilla.org/xmlextras/xmlhttprequest;1']. The DOM returned by responseXML is associated with the origin the XHR was initialized with. As far as how you set this origin, it used to be that you could do this directly from a component, but now it looks like we always use the principal of the associated window, if any. Unfortunately, we also use that window to determine whether this is a system XHR or not, as far as I can tell... Clearly there is a wrapper in play but exactly what kind of wrapper and how to penetrate it is not yet clear to me. You really want to just give that DOM the origin of the page you want to expose it to. I guess the reason I'm suddenly having this problem is https://bugzilla.mozilla.org/show_bug.cgi?id=809652 Seems pretty unlikely. Can you pin down which nightly build the behavior change you observe happened in? See http://harthur.github.com/mozregression/ -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Accessing @mozilla.org/xmlextras/xmlhttprequest;1 from content
On 2/24/13 12:44 PM, matt...@salsitasoft.com wrote: Unfortunately I'm relying on DOMWindowCreated to inject my symbols into the window, and this is no longer fired in FF19 with the type set to chrome. Uh code inspection and basic testing over here suggest it fires just fine, for what it's worth. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Accessing @mozilla.org/xmlextras/xmlhttprequest;1 from content
On Sunday, February 24, 2013 4:27:16 AM UTC+1, Brian Smith wrote: > I notice that your company has developed a cross-browser framework for > building extensions. That means you are probably familiar with Chromium's > requirements here. I believe that Chromium requires you to do things the same > way as the Firefox Addon SDK recommends. (I'm not sure if that helps explain > my suggestion or not.) Exactly, we need to emulate Chrome's behavior in the background window (see http://developer.chrome.com/extensions/xhr.html). Specifically we need to be able to make cross-domain requests in the background window and requests to chrome:// and resource:// URLs. I've implemented the background window as a hidden XUL window with a embedded. Looking over my code before the switch from FF18 to FF19, I wasn't actually doing anything at all except setting the type attribute of the to chrome (i.e. the default). Unfortunately I'm relying on DOMWindowCreated to inject my symbols into the window, and this is no longer fired in FF19 with the type set to chrome. I guess I'll file a bug about this. I was naively looking for a quick fix by injecting my own XHR implementation but it looks like that's problematic as I described in my OP. I'll see if I can use the content-document-global-created notification or something. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Accessing @mozilla.org/xmlextras/xmlhttprequest;1 from content
On Friday, February 22, 2013 4:28:08 PM UTC+1, Kyle Huey wrote: > You should look at SpecialPowersAPI.createSystemXHR. It's what we use in > our test suite to do this. Hi Kyle, Thanks for this. I need to replace the XMLHttpRequest constructor with my own constructor, so I can't call createSystemXHR directly. I'll see if I can figure out from the code how to do this. Currently I have to admit that I don't understand how the code addresses the issue of giving content access to the responseXML DOM returned by the Cc['@mozilla.org/xmlextras/xmlhttprequest;1']. To reiterate my problem: I am replacing the default implementation of XMLHttpRequest with my own wrapper than delegates to Cc['@mozilla.org/xmlextras/xmlhttprequest;1']. Everything works fine except that the DOM returned by the responseXML property returns an error (Permission denied to access property 'documentElement') when I try to retrieve its properties. Clearly there is a wrapper in play but exactly what kind of wrapper and how to penetrate it is not yet clear to me. I guess the reason I'm suddenly having this problem is https://bugzilla.mozilla.org/show_bug.cgi?id=809652 but I can't be sure since I don't have access to it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Accessing @mozilla.org/xmlextras/xmlhttprequest;1 from content
- Original Message - > From: "Matthew Gertner" > To: dev-platform@lists.mozilla.org > Sent: Friday, February 22, 2013 7:02:40 AM > Subject: Accessing @mozilla.org/xmlextras/xmlhttprequest;1 from content > > I have an extension that loads an HTML file into a hidden > and runs script in the context of the hidden browser window. That > script needs to be able to make crossdomain XHR requests to > chrome:// and resource:// URLs that are apparently now blocked in > Firefox 19 (they weren't blocked in Firefox 18). I believe that the Addon SDK (a.k.a. JetPack) has special provisions for this; See [1], section "Content Scripts." In particular, I think that if you inject a "content script" into the then the "content script" will be able to make cross-origin requests like you propose. At least, I know that the Addon SDK required an extension to the nsIPrincipal interface to support multi-origin principals for this case. I am particularly interested if this strategy would work for you and other addon developers. Cheers, Brian [1] https://addons.mozilla.org/en-US/developers/docs/sdk/1.12/dev-guide/guides/xul-migration.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Accessing @mozilla.org/xmlextras/xmlhttprequest;1 from content
On Fri, Feb 22, 2013 at 7:02 AM, Matthew Gertner wrote: > Is there a better way to let content do crossdomain XHR? Or is there a > good way to provide a usable XML DOM from chrome to content? I can always > reparse responseText to create my own DOM if there's a way to create a > content-friendly DOM. > You should look at SpecialPowersAPI.createSystemXHR. It's what we use in our test suite to do this. There's also a systemXHR facility built into Gecko for allowing certain sites to do cross-origin XHRs without CORS that's being used for b2g, but I don't think it works to chrome or resource protocols. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
