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 sandb
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 refere
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 expand
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.or
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(
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.
___
de
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
Appa
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 unde
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 pol
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 i
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
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 con
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?
__
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
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 c
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 conten
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
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 "permi
On Thursday, October 10, 2013 6:58:24 PM UTC+2, Boris Zbarsky wrote:
> That's ... quite odd. Scripts loaded via a
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 co
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).
&
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 mod
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 functio
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 lookin
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
d
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 lo
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 throug
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 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 subjec
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
andling 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'
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
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 corr
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 s
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
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
'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 implem
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 re
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 cod
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.cg
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 htt
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
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 obj
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
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 f
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
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 win
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.mozIJSSubScriptLoa
ell. 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
>>
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 1
50 matches
Mail list logo
