Re: Loading data into browser with type == chrome
On Tuesday, February 26, 2013 3:46:35 PM UTC+1, Boris Zbarsky wrote: I thought you were implementing a custom protocol handler? If you are, then you can just use whatever channel you want. If you're not, of course, messing with the channel won't help anything. I am, but that wouldn't help the fundamental problem with DOMWindowCreated not being fired. But (with your help) I found a much better solution anyway (see below). I added URI_INHERITS_SECURITY_CONTEXT to my protocolFlags and now it works. I really hope your protocol is not loadable from the web at large This is a good point. Our framework makes it possible to use Chrome extensions in Firefox, and since they moved to manifest v2 they have a new config property called web_accessible_resources that specifies exactly which files can be accessed from content. This is needed since in some cases you'll want to inject some HTML into a webpage and have it load e.g. stylesheets or images from the extension. As per your suggestion, I implemented a wrapper for the normal nsIFileChannel that overrides the stream listener's onStartRequest and throws NS_ERROR_DOM_SECURITY_ERR if the URL isn't whitelisted. I think I really have to use URI_LOADABLE_BY_ANYONE in my protocolFlags, so this mitigates the security risk. As an aside, it took me a full day to figure out how to wrap the nsIFileChannel. Turns out you *must* override the nsIStreamListener/nsIRequestObserver methods as well so that they are called with the wrapper, not the underlying channel as the request, otherwise XHR doesn't start the request (see http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsXMLHttpRequest.cpp#2016). If anyone is interested, feel free to use my ChannelWrapper (https://github.com/salsita/ancho/blob/develop/firefox/js/channelWrapper.js). I had to wrap IWritablePropertyBag2 and friends as well. Shall I file a bug Please do! https://bugzilla.mozilla.org/show_bug.cgi?id=845780 Matt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Loading data into browser with type == chrome
On Monday, February 25, 2013 8:40:45 PM UTC+1, Boris Zbarsky wrote: On 2/25/13 1:46 PM, matt...@salsitasoft.com wrote: So are you suggesting that I create the chrome:// URI channel myself and load from it after changing the originalURI? Yes, I think so. I couldn't see a way to load the document via the channel. nsDocShell::LoadURI() does an awful lot. However, I took a peek at the source and noticed http://mxr.mozilla.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp#2378. It looks like in a chrome docshell Firefox wants the document to have the system principal or it doesn't fire DOMWindowCreated. I added URI_INHERITS_SECURITY_CONTEXT to my protocolFlags and now it works. Based on the comment above the nsGlobalWindow code, this looks like a bug to me since it is catching cases other than the about:blank situation it appears to be designed for. Shall I file a bug or do you think this behavior is intended? Matt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Loading data into browser with type == chrome
On 2/25/13 12:36 PM, matt...@salsitasoft.com wrote: As discussed in https://groups.google.com/d/topic/mozilla.dev.platform/E4MG_hTv6Zw/discussion, I am not getting the DOMWindowCreated message when I use a browser element with type set to chrome Depending on what you're doing, you could just be seeing the about:blank inner window reused. Ideally I would use my own protocol handler to load the document, but I haven't had any success due to the aforementioned problem with DOMWindowCreated. I tried setting the protocolFlags to URI_DANGEROUS_TO_LOAD but that doesn't help. I'm not clear on why the protocol handler would depend on DOMWindowCreated 2) Barring that, can I change the baseURI of the document when DOMWindowCreated is fired (i.e. before the scripts are loaded)? In that case I would load the document from the chrome:// URL but change the baseURI to use my own protocol. You can set your channel's originalURI to whatever you want (which may not match where the data is loaded from, which is the URI), right? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Loading data into browser with type == chrome
On Monday, February 25, 2013 6:58:44 PM UTC+1, Boris Zbarsky wrote: Depending on what you're doing, you could just be seeing the about:blank inner window reused. Specifically, I need to be able to inject properties into the window before any script is run. When I load with a chrome:// URL, DOMWindowCreated is fired so I can inject my stuff there. When I load from a resource:// URL or via my own protocol, it isn't fired. I tried adding properties to the window before the load (under the hypothesis that the inner window is being reused), but they don't seem to be there after the load. If the window is being reused, do I have any opportunity to inject my own properties? I'm not clear on why the protocol handler would depend on DOMWindowCreated See above. You can set your channel's originalURI to whatever you want (which may not match where the data is loaded from, which is the URI), right? So are you suggesting that I create the chrome:// URI channel myself and load from it after changing the originalURI? I could try that. If I can figure out a way to load using my own protocol handler then the problem goes away since I can make myprotocol://foo/bar point to the same location as chrome://foo/content/bar and the relative paths will resolve properly. Matt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Loading data into browser with type == chrome
On 2/25/13 1:46 PM, matt...@salsitasoft.com wrote: I tried adding properties to the window before the load (under the hypothesis that the inner window is being reused), but they don't seem to be there after the load. Then the inner window is not being reused. You can set your channel's originalURI to whatever you want (which may not match where the data is loaded from, which is the URI), right? So are you suggesting that I create the chrome:// URI channel myself and load from it after changing the originalURI? Yes, I think so. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
