Forgive me for just pasting an IRC transcript in here, but this has a lot of details about what we need. The basic premise is in the following chunk; the rest is details. * bz (bzbarsky@538BABFE.A073F3E.97BBD552.IP) has joined #b2g <bz> cjones: so if you have a few mins... <bz> cjones: right now the home screen is loaded in a content-primary docshell <bz> cjones: is there a reason to not use a chrome docshell there? <cjones> bz, the homescreen is a regular webapp with some extra permissions granted <cjones> that's the model <cjones> if it's expedient for us to prototype some features, we can temporarily grant it chrome privs <bz> that model breaks down when we want to impose constraints like window.top not bein the home screen <bz> I'm not talking about chrome privs <bz> I'm talking a chrome-type docshell <bz> so in particular, for the b2g browser, we need to use a different docshell type for the web pages and the browser ui <cjones> so the chrome-type docshell is what knows to pretend like it's the top of the hierarchy <cjones> ? <bz> so we either need to make the latter chrome-type or introduce a third docshell type <bz> cjones: what knows that is a content type docshell whose parent is chrome type or nonexisten <bz> er, nonexistent <cjones> we would want that for all apps <iframe>s, right? <cjones> what different would it make for the homescreen itself? <cjones> *difference * jhammink has quit (Ping timeout) <bz> well, right now in gecko content type iframes can only have content type descendants <bz> so in order to make the browser ui chrome type any ancestors of the browser ui also need to be chrome type <cjones> i see <cjones> or the third type <bz> (or we need some gecko changes etc) <bz> or yes <cjones> it seems like that would be a generally useful feature, right? <bz> which? <cjones> be able to embed an iframe without giving it access to window.top <cjones> (which IIUC is one of the magic bits flipped by chrome-type docshell?) <philikon> where do we need it besides the homescreen and other app-launcher thingies? <cjones> browser <philikon> oh right <philikon> it wants to have sub windows, but window.top should be correct within the website it displays <cjones> right <bz> yes <bz> so the main question is whether it's ok for window.top in apps to point to https://github.com/cgjones/mozilla-central/blob/master/b2g/chrome/content/shell.xul <bz> if it's not, we need a third docshell type <cjones> in the long run, i don't want that <bz> ok <bz> so in the long run it sounds like we need three separate docshell types <bz> or something <cjones> we would need that docshell type for the internal browser iframe anyway right? <bz> and a bunch of auditing <cjones> irrespective of the home screen <bz> on the other hand, long-term we can make the browser use e10s <bz> so .top will Just Work in web pages <bz> and then we can make apps and the browser ui type="content".... <bz> cjones: not sure what you mean about internal browser iframe <cjones> the iframe into which the browser app loads cnn.com, say <cjones> but yeah, if it's remote the problem kinda goes away <cjones> i would be slightly uncomfortable about requiring oop for the browser though <bz> ok <bz> so then long-term we need 3 docshell types <bz> or some other condition for cutting off the docshell tree at the browser ui <cjones> are there any issues you foresee in letting general web content use this third type? <bz> either way we have to audit all current users of docshell types in the tree... <bz> hmm <bz> it would break frame-busting scripts, right? <cjones> (this is still all orthogonal to the permissions issue, AIUI) <cjones> correct <bz> that's no good <cjones> that seems good or bad depending on which side you're on <bz> well <bz> for our browser we want it <bz> because it's trusted <bz> for untrusted content, it's not ok <bz> so using this third type should involve elevated permissions <cjones> why do we need to keep frame-busting working? <cjones> can't sites use X-Frame-Options? <bz> that will break too <bz> because it needs to be ignored in the browser <bz> so keyed off the same mechanism <cjones> oh i was assuming that would continue to work <cjones> gotcha <cjones> ignoring X-Frame-Options definitely needs elevated perms <bz> right <bz> and I think the two should just go hand in hand <bz> imo <cjones> if we tie both those together should be fine <cjones> yeah <bz> ok <bz> so we need a third type for either the stuff the browser loads or for "home screen and apps" <bz> I'd sort of lean toward creating a third type for the latter <bz> since they're the new piece of the puzzle <cjones> i think what the home screen / app launcher needs to do is a small subset of what the browser app needs to do * bz is not sure why that's relevant * You are now known as jlebar <cjones> i wouldn't even care about the home screen for now <bz> what I would like to preserve is the invariant that our docshell types are strictly ordered <cjones> ah <bz> and that if A > B then B can have no descendants of type A <bz> because it makes reasoning about all sorts of stuff way easier <cjones> i understand <cjones> we can do all that together then <bz> ok <bz> Is Ben Francis the right man to do this? <bz> or do we need someone else? <cjones> he said he's not too comfortable in platform code <bz> ok <cjones> someone else for Gecko <bz> I could probably do it, but then reviews are a possible issue <bz> if someone does it, I'm happy to review <cjones> i'm a review slave now <bz> yeah <cjones> but i shouldn't really review that code <bz> can we try smaug or jlebar? * dougt|away is now known as dougt <cjones> sure * jlebar reads the scrollback <bz> (smaug is the other possible reviewer) <cjones> smaug has been responsive lately * dougt is now known as dougt|away <cjones> bz, so i guess this new docshell type and the magic frame-script-y thing are pretty much all we need, eh? <jlebar> bz, If you'll review and help me understand, then I can write the patch. <bz> cjones: I think so <bz> jlebar: totally happy to do that <bz> cjones: the magic system-principal frame-script-y thing <cjones> jlebar++ <bz> cjones: well, and more event firing, etc <bz> jlebar: thank you! <cjones> bz, the script can fire events, right? <cjones> for now <cjones> prototyping <cjones> frame script in content postMessage() back to parent, listener in browser-prototype.js fires dom event based on the message <cjones> then we build browser-prototype.js into gecko eventually <cjones> and the frame-script stuff * dherman (dherman@B032AFC4.8682FA05.369F669D.IP) has joined #b2g <bz> cjones: yeah <bz> cjones: that works <cjones> sold
So this bug is about a third docshell type? You can already load non-chrome-privileged documents in chrome-type docshells.....
<bz> so the main question is whether it's ok for window.top in apps to point to https://github.com/cgjones/mozilla-central/blob/master/b2g/chrome/content/shell.xul <bz> if it's not, we need a third docshell type So the purpose of the third type is so that you can have b2g/chrome/content/shell.xul <-- top-level app <-- unprivileged chrome docshell but have window.top from the app point to the app, rather than shell.xul?
We need a third type because we want window.top in the pages loaded in the b2g web browser to point to the toplevel web page, not the browser window itself and because cjones wants window.top in an app to point to the toplevel page of the app, not to the window manager, if I understood correctly. So we need two separate docshell boundaries. At least two, that is.
Can we have a flag which says "I'm a window.top boundary", rather than trying to enumerate these boundaries individually?
Summary: Allow pages to have chrome-type docshells without chrome privileges → Allow (privileged) frames to indicate that they're a window.top boundary
We could. We'd need to audit all code using docshell types in the process, but we may have to do that anyway.
Is suppressing X-Frame-Options headers for special iFrames within the scope of this bug, or should I file a separate bug?
Separate bug, please.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 725796
You need to log in before you can comment on or make changes to this bug.