Removing expando properties from window wrapper when freeing sandbox
I'm using Cu.evalInSandbox in a bootstrapped extension to run code in an isolated environment using a content window as the sandbox prototype. When the code adds expando properties to the window (e.g. jQuery), the sandbox predictably leaks when the extension is disabled. I assume that the sandbox gets an Xray wrapper for the window that is specially created for it. What is the best way to remove all expando properties added in the sandbox or otherwise destroy this wrapper when the extension is disabled? The best idea I'm having is to set wantXrays to false when creating the sandbox and pass in my own wrapper using Object.create(window). That way I can iterate over the wrapper when I want to free the sandbox and null out any own properties. Does that make sense or is there a cleverer way I'm missing? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing expando properties from window wrapper when freeing sandbox
On Wednesday, April 17, 2013 3:57:58 PM UTC+2, Bobby Holley wrote: > When you want the sandbox to die, you can do > |Components.utils.nukeSandbox(sandbox)|, and it'll go away. Simple as that. > > :-) Awesome, exactly what I was looking for! I'm not sure how I missed that (would be good to reference it from https://developer.mozilla.org/en-US/docs/Components.utils.Sandbox although I really should have found it anyway). > > The best idea I'm having is to set wantXrays to false when creating the > > sandbox and pass in my own wrapper using Object.create(window). That way I > > can iterate over the wrapper when I want to free the sandbox and null out > > any own properties. > That is indeed clever, but has the potential to break a lot of the special > handling we do to make |this|-bindings work properly in conjunction with > sandboxPrototype. This stuff already pushes the boundaries a little bit, so > I'd shy away of clever tricks like that lest they end up being broken down > the line. Yeah, I played around with this a bit today, and it seems problematic from a number of perspectives. Apart from anything else, the wrapper serializes as "[object Object]" and would probably cause issues with code that is expecting a window. Thanks for your help. I'm trying out nukeSandbox now. Matt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing expando properties from window wrapper when freeing sandbox
On Wednesday, April 17, 2013 3:57:58 PM UTC+2, Bobby Holley wrote: > When you want the sandbox to die, you can do > |Components.utils.nukeSandbox(sandbox)|, and it'll go away. Simple as that. > :-) I've been using this, and it indeed nukes the sandbox even if there are backreferences from expando propertie external to the sandbox. However, the sandbox lives on if it contains DOM event handlers that have not been removed. Is this by design? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing expando properties from window wrapper when freeing sandbox
Boris - sorry, these are event listeners. Bobby - that would rock. I'm removing the event listeners manually but this requires some hardcoded dependencies to jQuery that I'd love to get rid of. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Stylesheet loaded from privileged channel does not trigger content policy for subresources
My extension is injecting markup and script into content pages from a protocol implemented by my own handler (nsIProtocolHandler). Because in some cases I need script loaded via this protocol handler to have chrome privileges, I am setting the channel owner to the system principal in newChannel(). All of this worked great, but I also need to block certain content loaded via my protocol handler. For this purpose I implemented a content policy (nsIContentPolicy). I noticed that when a stylesheet is loaded using my protocol handler, the content policy's shouldLoad() method is not triggered for subresources loaded by the stylesheet. If I remove the line that sets the owner of the stylesheet's channel to the system principal, then shouldLoad() is triggered for e.g. background images as expected. Is it normal that subresources loaded by a stylesheet from a privileged channel do not trigger the content policy? If so, is there any way around this other than to not have the stylesheet's channel have the system principal? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Stylesheet loaded from privileged channel does not trigger content policy for subresources
On Thursday, May 2, 2013 1:40:37 AM UTC+1, Boris Zbarsky wrote: > Yes. Content policy checks are skipped when the loader has system > principal. Thanks. Seems like I need to be more selective about when to give the channel the system principal. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Error on startup when registering content policy from bootstrapped extension
I'm registering a content policy (implemented in JavaScript) from the startup() function of my bootstrap.js. When I do so, I get an error in the Error Console: Timestamp: 5/10/13 4:50:56 PM Error: this.webNavigation is null Source File: chrome://global/content/bindings/browser.xml Line: 721 Apparently the constructor is being called before the docShell is there. I can't see why registering a category entry with type "content-policy" would cause this, however. From the code it looks like the entry just gets put into the list maintained by nsContentPolicy (it uses nsCategoryCache for this). The list is iterated in CheckPolicy. Why this would cause the to be instantiated prematurely is not clear to me. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Error on startup when registering content policy from bootstrapped extension
On Friday, May 10, 2013 6:15:59 PM UTC+2, Boris Zbarsky wrote: > Is your policy being called with the subject set to the ? Just before the error occurs, the policy is called with aRequestOrigin set to chrome://browser/content/browser.xul and aContentLocation set to about:blank. I just don't understand why the existence of the policy causes the to be instantiated since as far as I can see CheckPolicy is called whether the mPolicies list is empty or not. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Error on startup when registering content policy from bootstrapped extension
On Saturday, May 11, 2013 11:29:58 AM UTC+2, Matthew Gertner wrote: > Just before the error occurs, the policy is called with aRequestOrigin set to > chrome://browser/content/browser.xul and aContentLocation set to about:blank. > I just don't understand why the existence of the policy causes the > to be instantiated since as far as I can see CheckPolicy is called whether > the mPolicies list is empty or not. Sorry I should have said just *after* the error occurs. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Error on startup when registering content policy from bootstrapped extension
On Saturday, May 11, 2013 7:37:00 PM UTC+2, Gavin Sharp wrote: > I believe bz's theory is that the 's binding was being > force-applied because the was being wrapped to be passed to > your JS-implemented content policy (as aContext). XBL bindings are > force-applied when an element in a document is JS-wrapped and its > binding hasn't yet been applied through normal mechanisms (i.e. > layout). That makes sense. So is it a bug that this causes an error to be logged in the Error Console? It seems to me that I should be allowed to register a content policy at startup (before the first browser window is loaded) without getting error messages. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Error on startup when registering content policy from bootstrapped extension
https://bugzilla.mozilla.org/show_bug.cgi?id=871176 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Error on startup when registering content policy from bootstrapped extension
On Sunday, May 12, 2013 12:25:59 AM UTC+2, Neil wrote: > But the original error was that the webNavigation was null... so what's > loading the about:blank in the first place? about:blank is being loaded because the browser is starting up and restoring the old session. As I understand it, the context of the about:blank load is the and the XBL binding is being forced before the browser docshell is there in order to invoke my JS-implemented content polcy. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Error on startup when registering content policy from bootstrapped extension
On Sunday, May 12, 2013 5:54:04 PM UTC+2, Neil wrote: > browsers don't load documents, doc shells do. So, my question is again, > where's the doc shell that's loading the about:blank? Ah, I see your point. Maybe it's there but not associated with the boxobject yet? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Deferred display of XUL panel containing embedded iframe
I have a toolbar button that displays a XUL panel when pressed. The panel contains an iframe into which an HTML page is loaded. To avoid "flicker", I'd like to defer display of the panel until the HTML page has finished loading (DOMContentLoaded). I tried setting the panel's hidden property to true in the popupshowing handler and then setting it back to true when the iframe has finished loading. The DOMContentLoaded handler for the iframe is called, but the panel remains invisible even after setting hidden back to false. The state of the panel is 'closed' at this point. It seems like the panel is automatically being closed when its hidden property is set to true. (The same happens when I set style.display to 'none' or collapsed to true). I nosed around the source code a bit but ended it quickly in the bowels of nsBoxObject.cpp. Before I start debugging the box object code, does anyone have any insights into why setting the hidden property of the panel's XUL element to true causes it to be closed (and thus remain invisible even when hidden is set back to false)? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Deferred display of XUL panel containing embedded iframe
On Thursday, May 16, 2013 7:20:33 PM UTC+2, Gavin Sharp wrote: > Can't you just avoid calling openPopup until the page is loaded, and > avoid messing with the panel's "hidden" state completely? I tried that but it seemed like the iframe didn't have a docShell until after the popup is shown so I couldn't load the document into it. If that seems strange then I'm probably doing something wrong (I only did a quick test earlier today). I'll have to investigate further. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Deferred display of XUL panel containing embedded iframe
On Friday, May 17, 2013 12:20:13 AM UTC+2, Neil wrote: > display: none; destroys the nsIFrame object (in this case an > nsMenuPopupFrame), thus closing the panel. Is there another way to make the panel invisible without destroying the nsIFrame? I can't see how to open the popup after the content is loaded since as far as I can see the iframe doesn't have a docshell until the popup is first opened. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Deferred display of XUL panel containing embedded iframe
On Friday, May 17, 2013 10:40:12 AM UTC+2, Matthew Gertner wrote: > Is there another way to make the panel invisible without destroying the > nsIFrame? For the record two people emailed me separately to suggest panel.style.visibility = 'hidden'. This works fine. The only caveat is that I still see the panel's old content for a split second if I make it visible again in the 'DOMContentLoaded' handler. If I wait for readystate to change to 'complete' then it works fine and I see the new content with no blinking. I'm not sure if this is because rendering has not necessarily finished when readystate is 'interactive' or if it's just coincidence (since 'complete' happens later). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Solving cross-origin script problem ("permission denied") when using custom protocol handler
I have a page in my extension loaded from my own protocol handler. This page loads script both from the local disk (using the same protocol handler) and remote script loaded via HTTPS. When I try to access properties on objects instantiated in the remote script from my local script, I get "permission denied" errors. I assume that I need either to subsume the principal of the remote site in my principle or relax the content security policy (similar to what can be done with the HTTP Content-Security-Policy header). Is there some way to do either of these programmatically with my own protocol handler? Something like nsIExpandedPrincipal looks perfect but it doesn't seem to be usable from JavaScript. I thought I could maybe set the nsIChannelPolicy on my channel a la http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsCSPService.cpp#302 but it doesn't seem to be using my CSP at all when I do that (no debug calls to shouldLoad() and company). And I'm not sure the CSP is what controls access to object properties in cross-origin scripts anyway (certainly the script is successfully loading so shouldLoad() is presumably not the culprit). So my questions are: 1) Is the CSP what determines whether a script can access properties in another script from a different origin? 2) If so, is there some way to set the CSP for a channel in a way that will be actually picked up and used? 3) If not, do I need a special principal for my channel? 4) If so, is there some way to do this in JS? I see a lot of [noscript] methods. Matt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Solving cross-origin script problem ("permission denied") when using custom protocol handler
On Thursday, October 10, 2013 6:58:24 PM UTC+2, Boris Zbarsky wrote: > That's ... quite odd. Scripts loaded via a
Re: Solving cross-origin script problem ("permission denied") when using custom protocol handler
On Thursday, October 10, 2013 7:23:44 PM UTC+2, Boris Zbarsky wrote: > Seems unlikely. Indeed, I completely misdiagnosed the issue. Upon further investigation it turns out that the external script is trying to set a property on a chrome object and that __exposedProps__ does not allow this. So completely normal behavior. What I can't seem to figure out is how to make it so that content can add new properties to a COW (as opposed to modifying existing properties). Totally different question, I know, but is this possible? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Solving cross-origin script problem ("permission denied") when using custom protocol handler
On Friday, October 11, 2013 12:53:27 PM UTC+2, Bobby Holley wrote: > On Fri, Oct 11, 2013 at 10:24 AM, Matthew Gertner > > What I can't seem to figure out is how to make it so that content can add > > new properties to a COW (as opposed to modifying existing properties). > > Totally different question, I know, but is this possible? > It's not really, and COWs are deprecated. What kind of object is this, > > and why does content need to modify it? Just to close this thread off: a) The original premise was wrong and there is no cross-origin issue (as Boris pointed out). b) Bobby pointed me at http://mxr.mozilla.org/mozilla-central/source/dom/base/ObjectWrapper.jsm (IRC discussion) and I'm planning to port my COWs to use that. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Overriding content window methods with chrome functions
I'm loading a page into a but I want the close()
method to call a function defined in chrome. I tried the obvious:
window.wrappedJSObject.close() = function() { ... };
However, the old close() method is still called (as far as I can tell). I guess
I'm being thwarted by some wrapper despite modifying wrappedJSObject?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Overriding content window methods with chrome functions
On Monday, October 21, 2013 4:40:08 PM UTC+2, Gijs Kruitbosch wrote:
> Uh, I hope you meant:
> > window.wrappedJSObject.close = function() { ... };
> (ie, no braces after close[()])
Sorry, yes of course. I typed that quickly but obviously the real code doesn't
have parentheses after the function name, and the problem as stated still
stands.
> But *if* you're managing to touch the underlying object, that's a
> security issue waiting to happen, AIUI (what if content defines a setter
> function on the window's "close" property?). CC'ing bholley who gave a
> talk[0] about this stuff and knows more about this (and might have
> solutions and/or assuage my fears as to the security of this).
I'm not sure I see the security risk. If content defines a setter on close()
then... what? Worst case it can access the chrome function that I'm trying to
give it access to anyway.
FYI I load the content into a popup and I want it to be able to close the
popup. So the real chrome function looks like:
contentWindow.wrappedJSObject.close = function() {
chromeWindow.close();
};
But as I said, the default close() method seems to be called instead and I get
an error about not being able to close a window that wasn't opened using script.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Overriding content window methods with chrome functions
On Monday, October 21, 2013 5:45:44 PM UTC+2, Neil wrote: > Well, you could turn of that error; it's just a pref. Of course you > would then decide whether to trap all the other DOMWindowClosing events > to stop other random scripts from closing windows. > > Alternatively, you could maybe looking into setting the window to have > an app docShell, in which case it's allowed to close itself. I can't really change the user's prefs, and the scripts are all trusted so there isn't a problem there. What exactly do you mean by setting the window to have an app docShell? You mean load it into a browser with type = "chrome"? Unfortunately I can't do that if I want it to have localStorage. I think there must be a way for me to override the close() method of the window. I'll have another look and confirm that I am really setting it on the unwrapped window object. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Overriding content window methods with chrome functions
Turns out I was changing the method on a wrapper after all. Weird since I pass obj.wrappedJSObject into the function but I guess it gets wrapped again (maybe because I am passing it from one subscript context to another). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Giving a content page cross-origin rights for loading font faces
Normally pages are not allowed to load font faces from other origins (see https://bugzilla.mozilla.org/show_bug.cgi?id=604421). If I am chrome and want to give a content page the right to do this (from specific domains or ideally from anywhere), is that possible? Note that the content page is loaded using my own custom protocol handler, if that makes any difference. Matt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Removing a window from the session store
I am trying to close a popup browser.xul window during Firefox shutdown so that it won't get loaded on restart by the session saver. I close the window before the browser shuts down (e.g. on quit-application-requested) but it is still opened when I start the browser again. After trawling through SessionStore.jsm, it looks like the problem is that the session store "freezes" the session on quit-application-requested so that it doesn't accidently lose windows that are closed as a normal part of the shutdown process. It wasn't immediately obvious to me how to circumvent this behavior. The only idea I have is to grab the state with SessionStore.getBrowserState(), remove my window manually and then set it back with SessionStore.setBrowserState(). Is there an easier way to do this? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing a window from the session store
On Wednesday, October 23, 2013 2:36:12 PM UTC+2, David Rajchenbach-Teller wrote: > At the moment, there is no good way to do what you need. The only > solution I can think of would be to configure your popup to be in > private browsing mode. Would that work for you? That might be a good solution. The side effects (not adding the page to history, etc.) are probably things we want anyway. Should I file a bug about this? It seems to me that it should be possible to close a window during shutdown without it being restored on restart. The most flexible option might be an API to cause a window to opt out of session saving completely. Matt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing a window from the session store
The private browsing approach didn't work for me since there is a visible indication in the title bar that the window is private, which I don't want. I ended up solving this by observing sessionstore-state-write and changing the session data manually (possible since it is passed in as the subject using nsISupportsString). Not very convenient but it works. I also filed https://bugzilla.mozilla.org/show_bug.cgi?id=930713. Matt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing a window from the session store
On Thursday, October 24, 2013 10:07:18 PM UTC+2, David Rajchenbach-Teller wrote: > Please don't do that, we are going to remove the nsISupportsString from > sessionstore-state-write soon. > > (So far, there is a single add-on that uses it, so we're busy preparing > an API for that add-on before we remove that. Please don't make our > life harder :) ) Can you suggest some other means to do what we need? I don't want to make anyone's life harder but I spent far too long on this problem and didn't come up with another solution. Matt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing a window from the session store
So if I understand correctly, a window that contains a single private tab will have no visual indication that the tab is private and will also not be restored by the session saver? This would meet my current requirements as long as it's possible to set the tab to private after creation (since I won't know until shutdown whether I want the window to be restored or not). That said, this seems like a worse hack than what I am doing now. Why are you getting rid of the nsISupportsString in sessionstore-state-write? Is there some urgency to doing this? Can't you fix https://bugzilla.mozilla.org/show_bug.cgi?id=930713 before you remove it? This seems like a pretty big lack in the current session saver API and something that should be straightforward to implement. Cheers, Matt On Oct 25, 2013, at 11:40 AM, David Rajchenbach-Teller wrote: > We have partial handling of private tabs. SessionStore doesn't handle > them yet, but I can prioritize this. Would this be sufficient for your > needs? > > Cheers, > David > > On 10/25/13 9:11 AM, Matthew Gertner wrote: >> Can you suggest some other means to do what we need? I don't want to make >> anyone's life harder but I spent far too long on this problem and didn't >> come up with another solution. >> >> Matt >> ___ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> > > > -- > David Rajchenbach-Teller, PhD > Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing a window from the session store
On Oct 25, 2013, at 12:34 PM, Tim Taubert wrote: > Private tabs will be automatically excluded when bug 899276 has landed. > I don't know off-hand if setting a tab to private works even if the tab > has been around for some time but I think that might be possible. I guess this is implied by what you said, but just to be sure: if a window contains just one private tab, the whole window won't be restored (i.e. it won't just open an empty window with no tabs in it)? >> Why are you getting rid of the nsISupportsString in >> sessionstore-state-write? Is there some urgency to doing this? > > There is no "urgency" but we're currently in the process of rebuilding > big parts of SessionStore to make it perform better. Giving add-ons that > much access to data makes it really hard to implement any kind of caching. Fair enough. It would definitely be much better to have controlled access via the API. >> Can't you fix https://bugzilla.mozilla.org/show_bug.cgi?id=930713 before you >> remove it? This seems like a pretty big lack in the current session saver >> API and something that should be straightforward to implement. > > I understand that this feature seems important to you but I disagree > that is a "big lack" in the current API. This is the first time I hear > of a requirement like that. Also fair enough. I can't speak to the overall importance of this. It does seem like an obvious bug to me that if I call window.close() any time after quit-application-requested, the window just opens anyway next time I start Firefox. > Could you maybe describe what you are actually trying to achieve and > why? Is there any add-on code we could take a look at? Maybe we can > together find a different and better solution to your problem. The simple answer is that I'm opening a popup and I want to close it when the browser quits since the contents of the popup are specific to that particular session. The more complex answer is that our framework lets people run Chrome extensions in Firefox, so I want to be able to do what Chrome does in all circumstances. In Chrome if you close a window during browser exit, it stays closed. Anyway, if there's *some* way to do this then I'm not going to complain. I'm willing to descend to arbitrary levels of hackery if there's no other way. :-) But I'd be bummed if you get rid of the nsISupports in sessionsaver-state-write without there being any other way to work around this bug. Matt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing a window from the session store
On Friday, October 25, 2013 5:26:11 PM UTC+2, Ehsan Akhgari wrote: > Non-private windows containing private tabs is not well supported, > *please* don't do that. If all you want is a SessionStore exclusion > API, then please let's focus on getting that. That would be awesome! IMO the truly correct fix would be to have the session store take into account explicit calls to window.close() during shutdown. The way it's done right now is a tad hacky since it just ignores window closures regardless of the cause. If that's not feasible then some sort of exclusion API would be perfectly fine as well. The only reason I'm groping around for hacks right now is that there doesn't seem to be a clean solution. Matt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
DOMWindowCreated not fired for some frames
I registered a "DOMWindowCreated" listener for a tabbrowser in a standard browser.xul window. When I open www.khanacademy.org/login inside a tab, there is a frame in the page with the URL www.khanacademy.org/login?form=1. The listener seems to be fired for all other frames (including all other sites I have tested), but not for that one specific frame. Is this a bug or am I misunderstanding something about the way the "DOMWindowCreated" event works? Matt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: DOMWindowCreated not fired for some frames
On Tuesday, March 25, 2014 7:34:27 PM UTC+1, Boris Zbarsky wrote: > Is the url about:blank when the window is created, perhaps? It's hard > to say without knowing exactly what you're logging/measuring. Well I tried attaching a readyStateChange listener to every window so I could see if the real frame loaded later, but it just doesn't seem to trigger that event. I'll make a minimal test extension and file a bug. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Request principal in nsIContentPolicy implementation
I've been using an nsIContentPolicy implementation to restrict access to resources that use my protocol handler. Specifically, I only want to allow access for requests that come from content under certain circumstances. To check whether the request comes from privileged code, I've been comparing aRequestPrincipal in the shouldLoad() method with the system principal. As far as I can tell, this has always worked. But now the comparison is failing, probably because I upgraded to Firefox 28. I looked, and for requests from chrome the request principal now seems to be null. For the requests from the browser URL bar it is the "null principal". Has something changed in Firefox 28 in this respect? What is the right way in the shouldLoad() method to check whether the request is coming from privileged code or content? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Request principal in nsIContentPolicy implementation
Hi Tanvi, I wasn't very clear about this, but the problem occurs when loading the main HTML document (either into a element or directly into a normal tab). I guess it's normal that the null principal is used for the main document when a URL is entered into the URL bar. Perhaps I'm getting null for the principal when loading it into my own since the previous document is about:blank. Anyway, I adapted the code and it seems to work now so this doesn't seem to be an issue. Thanks for your response, Matt On 14 May 2014, at 07:37, Tanvi Vyas wrote: > Hi Matthew, > > Are you using any other addons that could be calling into nsIContentPolicy? > aRequestPrincipal is optional for non-gecko code, so perhaps another caller > isn't setting it[1]? > > You can also get the principal off the Context[2][3]. Depending on what > information you are trying to gather, this is actually more reliable if you > are looking for the principal of the top level page or iframe that is > attempting to embed a resource. For example, assume https://a.com embeds a > css file from https://b.com. The css file then invokes an image load. When > the content policies are called to see if the image can be loaded, the > aRequestPrincipal is actually https://b.com (the css file that is loading the > image) instead of the page the image is being loaded into (https://a.com). > But the principal associated with the Context in the call to shouldLoad() > will be https://a.com. So, if you are looking for the principal of the page > the resource is being loaded into, you should use the Context instead of the > aRequestPrincipal. If you want the loader of the resource, you should use > aRequestPrincipal. For more on this topic, you can read the discussion > here[4]. > > I am not aware of any changes that might be causing this issue in Firefox 28, > but I was out for a bit so may have missed it. If this is an issue with FF28+ > (and not because of a third party content policy caller), we can do some more > digging. > > ~Tanvi > > [1] > https://mxr.mozilla.org/mozilla-central/source/content/base/public/nsIContentPolicy.idl#234 > [2] > https://mxr.mozilla.org/mozilla-central/source/content/base/public/nsIContentPolicy.idl#234 > [3] Here's some debugging code that might help you along - > http://pastebin.mozilla.org/5010243 > [4] https://bugzilla.mozilla.org/show_bug.cgi?id=909920#c14 > > >> >> ---- Original Message >> Subject: Request principal in nsIContentPolicy implementation >> Date: Mon, 5 May 2014 05:00:00 -0700 (PDT) >> From: Matthew Gertner >> Newsgroups: mozilla.dev.platform >> >> I've been using an nsIContentPolicy implementation to restrict access to >> resources that use my protocol handler. Specifically, I only want to >> allow access for requests that come from content under certain >> circumstances. >> >> To check whether the request comes from privileged code, I've been >> comparing aRequestPrincipal in the shouldLoad() method with the system >> principal. As far as I can tell, this has always worked. But now the >> comparison is failing, probably because I upgraded to Firefox 28. >> >> I looked, and for requests from chrome the request principal now seems >> to be null. For the requests from the browser URL bar it is the "null >> principal". Has something changed in Firefox 28 in this respect? What is >> the right way in the shouldLoad() method to check whether the request is >> coming from privileged code or content? >> >> > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Overriding the CSP for privileged protocols
Our extension injects styles into webpages via a protocol defined using our own protocol handler using . We have our own nsIContentPolicy which we use to enforce which resources from this protocol can be injected into content pages. The problem is that on sites the enforce their own CSP, the resources may not be loaded. For example, github.com has script-src set to 'self' so it won't load stylesheets via our protocol. Is there any way to designate a protocol as privileged so that it overrides the CSP? From looking at the source code it seems like certain protocols (about, chrome, resource) are hardcoded to override the CSP but I couldn't see a way to define other privileged protocols. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Overriding the CSP for privileged protocols
On Thursday, June 5, 2014 5:50:23 PM UTC+2, Boris Zbarsky wrote: > The CSP implementation should be using protocol flags here instead of > hardcoding (and if it's not, bugs should be filed). And then your > protocol can set the relevant flags. I'll confirm (going to dive deeper into the CSP code today) and file bugs as appropriate. On Friday, June 6, 2014 2:06:48 AM UTC+2, Daniel Veditz wrote: > CSP should be doing that (it's not) and while that may solve your > specific problem it leaves the more common case unaddressed. If a user > has installed an addon that creates mashups (injects flickr images > maybe, or maps?) the user wants to see that content even if the page's > CSP is not expecting it. We need a more generic way to specify minimum > required CSP overrides than just "anywhere my protocol appears". > Depending on the protocol that could just as easily reintroduce the XSS > problems CSP is trying to prevent. Currently Firefox extensions can do many dangerous things, and it is a big philosophical question whether the resulting flexibility is worth the extra security risk (I feel strongly that it is). As things stand, it should be possible for responsible extensions such as ours (we implement our own nsIContentPolicy for our protocol) to do things like inject CSS into pages. Chrome's framework is much more restrictive and it allows this since their chrome-extension: protocol is whitelisted. Matt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Overriding the CSP for privileged protocols
On Thursday, June 5, 2014 5:50:23 PM UTC+2, Boris Zbarsky wrote: > The CSP implementation should be using protocol flags here instead of > hardcoding (and if it's not, bugs should be filed). And then your > protocol can set the relevant flags. Bug filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1021669 I got around this for the time being by registering my own @mozilla.org/cspservice;1 that delegates to the original one. Don't try this at home, kids. If you do try this at home, remember to refresh the category cache for content-policy if you want the change to be taken into account when you install a bootstrapped extension: var subject = Cc['@mozilla.org/supports-cstring;1'].createInstance(Ci.nsISupportsCString); subject.data = 'CSPService'; Services.obs.notifyObservers(subject, 'xpcom-category-entry-removed', 'content-policy'); Services.obs.notifyObservers(subject, 'xpcom-category-entry-added', 'content-policy'); And, of course, remember to put back the old factory when your extension is uninstalled (and refresh the category cache again). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: DOMWindowCreated not fired for some frames
On Tuesday, March 25, 2014 7:34:27 PM UTC+1, Boris Zbarsky wrote: > Is the url about:blank when the window is created, perhaps? It's hard > to say without knowing exactly what you're logging/measuring. I spent some more time looking into this. The problem is apparently that we are observing http-on-modify-request and getting loadContext.associatedWindow when it is triggered. For this particular iframe this causes the document to be created and DOMWindowCreated to be dispatched. Stacktrace is here: http://pastebin.mozilla.org/5362491. I'm not sure if I should be able to do anything useful with the DOMWindowCreated event in this case. The document has no location at that point and if I set a readystatechange handler it is never called. If I remove the access to associatedWindow in the http-on-modify-request handler then my DOMWindowCreated handler is invoked normally with the document location set. Is this a Firefox bug or somehow by design? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: DOMWindowCreated not fired for some frames
On Friday, June 6, 2014 4:28:35 PM UTC+2, Boris Zbarsky wrote: > On 6/6/14, 10:00 AM, Matthew Gertner wrote: > It's by design: when you ask for a window and we haven't actually > created one yet (because this is a new subframe that's doing its initial > load, say), we have to go ahead and create an about:blank one to return > to you. So what's the best way to hook into the window so I am notified when the real document is created? I checked and it looks like "beforescriptexecute" will work for me (since I only need to do something before the first script is run) but if there's an event that is guaranteed to fire when the document changes, that would be easier. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: DOMWindowCreated not fired for some frames
On Friday, June 6, 2014 6:33:27 PM UTC+2, Boris Zbarsky wrote: > The about:blank document is quite real, sadly... > > I'm not seeing anything obvious that gets fired when we reuse an inner > for a new document. At least nothing obvious in the window code. >From what I'm seeing, the document object that ends up there (window.document) >is not the same one as when DOMWindowCreated is fired. That said, I'm stumped >so far as to how to deal with this. Using "beforescriptexecute" is probably a >good time to do the stuff I need to do, but I'm afraid of memory leaks since >the event handler is a closure with references back to the window. So if I >don't remove it and no scripts ever run in that window then the whole thing >will probably leak. I thought about cleaning up when "unload" is fired but it appears to be fired for the "about:blank" document as well, so I have no way of knowing whether I can clean up or now. Maybe I can use weak references or something... ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: DOMWindowCreated not fired for some frames
On Friday, June 6, 2014 6:49:55 PM UTC+2, Boris Zbarsky wrote: > That shouldn't be an issue. The cycle collector should handle it. Just > make sure you don't have a reference to that event handler on any > long-lived chrome objects. OK well I'm using beforescriptexecute and hopefully it should be fine. Thanks for the advice. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Registering XPTs in a bootstrapped extension
I guess the "interfaces" directive is not support in the chrome.manifest of bootstrapped extensions. We're using nsIComponentRegistrar.registerFactory to register XPCOM components, but we also need to register some additional XPCOM interfaces. I spent some time looking into this but I couldn't find any examples of how to do this. nsIInterfaceInfoManager and nsIInterfaceInfoSuperManager might be relevant but none of the methods look obviously applicable. Does anyone know how to do this? Matt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Object prototypes and the content/chrome barrier
I am using the content-document-global-created observer topic to add a function
to content windows when they are created. The function is used to load a
subscript like this:
var foo = window.loadSubscript("spec"); // loadSubscript() uses the subscript
loader internally
So the subscript should run with chrome privileges (loadSubscript is a function
defined in chrome). If foo is a function then I can call it from content.
However, if foo is an object constructor, it's prototype doesn't get through to
the content page. In other words, imagine that loadSubscript looks like this:
function loadSubscript(spec) {
var context = {};
var scriptLoader = Cc["@mozilla.org/moz/jssubscript-loader;1"].
getService(Ci.mozIJSSubScriptLoader);
scriptLoader.loadSubScript(spec);
return context;
}
And the subscript is something like:
function foo() {
}
foo.prototype = {
do_something: function() { return "Hello, world!"; }
};
I would expect to see foo.prototype in the content page script at the beginning
of this message, but instead I see "undefined". I guess this is a security
issue but no warnings or errors are displayed when I test in a Firefox debug
build. Does anyone know what gives?
Matt
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Object prototypes and the content/chrome barrier
Obviously I meant:
scriptLoader.loadSubScript(spec, context);
(I also meant "its prototype" not "it's prototype. :-)
On Aug 7, 2012, at 3:51 PM, Matthew Gertner wrote:
> I am using the content-document-global-created observer topic to add a
> function to content windows when they are created. The function is used to
> load a subscript like this:
>
> var foo = window.loadSubscript("spec"); // loadSubscript() uses the subscript
> loader internally
>
> So the subscript should run with chrome privileges (loadSubscript is a
> function defined in chrome). If foo is a function then I can call it from
> content. However, if foo is an object constructor, it's prototype doesn't get
> through to the content page. In other words, imagine that loadSubscript looks
> like this:
>
> function loadSubscript(spec) {
> var context = {};
> var scriptLoader = Cc["@mozilla.org/moz/jssubscript-loader;1"].
> getService(Ci.mozIJSSubScriptLoader);
> scriptLoader.loadSubScript(spec);
> return context;
> }
>
> And the subscript is something like:
>
> function foo() {
> }
>
> foo.prototype = {
> do_something: function() { return "Hello, world!"; }
> };
>
> I would expect to see foo.prototype in the content page script at the
> beginning of this message, but instead I see "undefined". I guess this is a
> security issue but no warnings or errors are displayed when I test in a
> Firefox debug build. Does anyone know what gives?
>
> Matt
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Object prototypes and the content/chrome barrier
On Aug 7, 2012, at 9:27 PM, Boris Zbarsky wrote:
> On 8/7/12 9:51 AM, Matthew Gertner wrote:
>> function loadSubscript(spec) {
>> var context = {};
>> var scriptLoader = Cc["@mozilla.org/moz/jssubscript-loader;1"].
>> getService(Ci.mozIJSSubScriptLoader);
>> scriptLoader.loadSubScript(spec);
>> return context;
>> }
> ...
>> And the subscript is something like:
>>
>> function foo() {
>> }
>>
>> foo.prototype = {
>> do_something: function() { return "Hello, world!"; }
>> };
>
> Should there be a "new foo()" somewhere here?
Maybe this example isn't quite right since (as usual) I conflated the global
object and the context. I should have said something like:
var context = { properties: {} };
...
And in the subscript:
properties.foo = function() {
...
}
In other words, I am making the object constructor accessible outside of the
subscript.
>
> Does applying the patch in bug 780542 change behavior for you?
Based on the feedback in this thread, the behavior seems consistent with that
described in https://wiki.mozilla.org/XPConnect_Chrome_Object_Wrappers. When I
expose the prototype using __exposedProps__ then the problem goes away. So
unless you have reason for believing otherwise, I don't think this is a bug.
Matt
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Object prototypes and the content/chrome barrier
Thanks, Simon, that did the trick.
On Aug 7, 2012, at 6:16 PM, Simon Kornblith wrote:
> Have you tried:
>
> foo.__exposedProps__ = {"prototype":"r"};
>
> (If this is indeed the issue, you should probably set __exposedProps__
> for the prototype as well. Newer Firefox versions warn about missing
> __exposedProps__ on objects, although I think it's only required for
> functions ATM.)
>
> Simon
>
> On Aug 7, 9:51 am, Matthew Gertner wrote:
>> I am using the content-document-global-created observer topic to add a
>> function to content windows when they are created. The function is used to
>> load a subscript like this:
>>
>> var foo = window.loadSubscript("spec"); // loadSubscript() uses the
>> subscript loader internally
>>
>> So the subscript should run with chrome privileges (loadSubscript is a
>> function defined in chrome). If foo is a function then I can call it from
>> content. However, if foo is an object constructor, it's prototype doesn't
>> get through to the content page. In other words, imagine that loadSubscript
>> looks like this:
>>
>> function loadSubscript(spec) {
>> var context = {};
>> var scriptLoader = Cc["@mozilla.org/moz/jssubscript-loader;1"].
>> getService(Ci.mozIJSSubScriptLoader);
>> scriptLoader.loadSubScript(spec);
>> return context;
>>
>> }
>>
>> And the subscript is something like:
>>
>> function foo() {
>>
>> }
>>
>> foo.prototype = {
>> do_something: function() { return "Hello, world!"; }
>>
>> };
>>
>> I would expect to see foo.prototype in the content page script at the
>> beginning of this message, but instead I see "undefined". I guess this is a
>> security issue but no warnings or errors are displayed when I test in a
>> Firefox debug build. Does anyone know what gives?
>>
>> Matt
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
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'm trying to solve this by injecting my own XMLHttpRequest symbol into the
window that wraps @mozilla.org/xmlextras/xmlhttprequest;1. This means that the
content can instantiate an XHR with chrome privileges and no crossdomain
restrictions. The properties of the XHR object weren't visible in content when
I first tried this, but I solved this using __exposedProps__.
Now I get "Permission denied to access property 'documentElement'" when
accessing using the responseXML property. I tried setting __exposedProps__ = {
documentElement: "r" } but this doesn't appear to make a difference (presumably
because setting __exposedProps__ on a native wrapper doesn't work).
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.
Cheers,
Matt
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
