Closed Bug 864284 Opened 13 years ago Closed 8 years ago

Creating iframe with nsEP

Categories

(Core :: XPConnect, defect)

Product:
Core
Component:
XPConnect
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INACTIVE

People

(Reporter: gkrizsanits, Unassigned)

Details

There is a demand from the SDK side to create iframes with nsEP. https://github.com/mozilla/addon-sdk/wiki/JEP-Window So one obvious thing that is missing is an API to create a standalone nsEP from chrome code. Then we have createAboutBlankContentViewer which we might be able to use for creating an iframe with nsEP... I don't know much about that part tbh.
What's an "nsEP"?
(In reply to Boris Zbarsky (:bz) from comment #1) > What's an "nsEP"? nsExpandedPrincipal, which is our principal that subsumes multiple content principals. I'm kind of wary of this, but I guess we allow the creation of iframes with System Principal too, so maybe it's not so bad? We'll need to handle the interaction with XBL scopes, which currently assume that all iframes are either System Principal or content principal, and create an nsEP(contentPrincipal) in the latter case (which won't work here because we disallow nsEP(nsEP). Am I correct that this iframe would never actually be used to load documents? Boris, what do you think?
(In reply to Bobby Holley (:bholley) from comment #2) > (In reply to Boris Zbarsky (:bz) from comment #1) > I'm kind of wary of this I'm slightly worried too, but I hope it won't be that bad... > Am I correct that this iframe would never actually be used to load documents? What do you mean? Like loading content from some url, or something to render? In that case yes, you are correct. Currently what we have is iframes on the hidden window as an alternative. In general the whole point of it would be to have a scope for the addon module that behaves like a web developers would expect with all the html APIs (websocket, xhr, localStorage, etc.) but with limited capabilities compared to chrome. I CC Iralki since he is the original requestor for this feature, so he can correct me if I'm wrong.
I think creating random windows with random principals should generally be ok....
(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #0) > Then we have createAboutBlankContentViewer which we might be able to use for > creating an iframe with nsEP... I don't know much about that part tbh. You can probably just create a blank iframe, enter the correct compartment, and then invoke SetInitialPrincipalToSubject(). You could also create some kind of helper method that just allows you to pass the principal directly, but I don't want to expose that too widely.
Putting some more thoughts into this approach I have some worries... Like what would be the origin for a websocket created from an iframe like that? Or what would be the path of an indexeddb created with it... I could add an origin info to nsEP, and we do have a unique URI to each add-ons, but it does mean it won't just work out of the box and we need a list of DOM API we need to make to work with nsEP. Also this resource URI we have for add-on I think by default a chrome location... So I'm not sure yet how to put this right.
We should probably do more or less what we do for nsNullPrincipals here - generate some kind of GUID and use that.
(note that null principals are already very-much web-exposed. In particular, sandboxed iframes get a null principal, so we already have to handle GUID origins for any DOM stuff we want to expose in those cases).
(In reply to Bobby Holley (:bholley) from comment #7) > We should probably do more or less what we do for nsNullPrincipals here - > generate some kind of GUID and use that. So do the DOM API work with these GUIDs? Like local storage for example... Actually we already have a GUID for each addon, that we could just pass in. The idea I have in mind is a frameless window, with nsEP that has an origin all DOM API can use. This would come with a protocol probably like addon://GUID or something. For this to work I'm sure we need a bunch of stuff, I'm just not sure what exactly, but something like: 1., Creating an iframe with nsEP (should be easy I had this one working, should be tested though) 2., Associate addons with an URL and that URL with a certain principal. In particular, with an nsEP that has an URL, where the URL is based on addon specific protocol and the GUID of the addon. 3., Make sure that we don't assume anywhere that nsEP does not have an URL 4., Handle this special protocol where it's needed. My hope is that if I get these bits correctly all the DOM APIs will just work out of the box pretty much, without any quirks. With some luck I could even use this frame as a postMessage channel between content and add-on code. (addon could postMessage to content window with the window of this iframe as the source, so content can communicate back) Boris, Bobby, how crazy does all this sound to you? If it sounds like a good approach any idea what I should do for step 2 and 4?
Lots and lots of whack-a-mole? :(
(In reply to Boris Zbarsky (:bz) from comment #10) > Lots and lots of whack-a-mole? :( In terms of getting the APIs to work with funny origin strings? Don't we already have that issue for sandboxed iframes?
Yes, and probably yes.
(In reply to Bobby Holley (:bholley) from comment #11) > In terms of getting the APIs to work with funny origin strings? Don't we > already have that issue for sandboxed iframes? Who might know more about this? Also, how do apps handle these issues? Like for example how can apps use local storage?
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.