> Poking around, I discovered bug 806127, where jlebar struck the same basic > problem for b2g, which gave me the > clue for a work-around. If I grab the docShell for this frame and execute: > > docShell.setIsBrowserInsideApp(Ci.nsIScriptSecurityManager.NO_APP_ID);
You should check, if you haven't already, that if you do this, the frame gets the set of cookies you want. I'm not totally clear on how Necko handles this, but it's possible that this would cause the social API window not to share cookies with the rest of the browser. That's probably not what you want. I'm actually surprised that <browser remote=true> inside the hidden window does not count as top-level. This window should be the top-level window in its process. Unless you have an <iframe> inside the <browser remote=true>, and it's that <iframe> that you were setting as an app? If that's the case, could you merge the <iframe> and <browser remote=true>? (You could either use a <browser> or an <iframe mozbrowser>.) Feel free to find me on IRC if you want to talk about this synchronously. -Justin On Wed, Jul 24, 2013 at 10:50 PM, Mark Hammond <mhamm...@skippinet.com.au> wrote: > As a bit of background, I'm working on an enhancement to our "Social API". > We currently have the concept of a "FrameWorker", which is basically a > simulation of a SharedWorker implemented by hosting an <iframe> in the > hiddenDOMWindow. This iframe loads content from a (real) site, and needs > access to IndexedDB - so far, so good - it all works fine. > > The enhancement is that we'd like to host this in a <browser > remote="true"/>, so the content lives in its own process. Everything works > fine *except* IndexedDB. I've narrowed this down to the fact that IndexedDB > is not available in "3rd party" iframes (by design - bug 595307). It does > work fine when the iframe is hosted in the hidden window - the iframe is not > considered 3rd party (jst tells me on #developers that the hidden window > gets some special handling so this is all as expected.) > > My problem arises when I host the iframe in the <browser> element - this > special-case for the hidden window no longer applies. The parent browser is > about:blank and the iframe is on a real site, so suddenly the iframe is > considered 3rd party and IndexedDB access is blocked. The problem would > probably (ie, I haven't checked) go away if we just hosted the content > directly in the <browser> element (ie, dropped the iframe), but we'd prefer > to avoid that currently if possible (mainly so we can host multiple of these > iframes in a single remote process if desired) > > Poking around, I discovered bug 806127, where jlebar struck the same basic > problem for b2g, which gave me the clue for a work-around. If I grab the > docShell for this frame and execute: > > docShell.setIsBrowserInsideApp(Ci.nsIScriptSecurityManager.NO_APP_ID); > > then everything works fine - the 3rd-party checking code sees the frame as > an "app boundary" and allows access to indexeddb - and life is good - except > for this hack I need to explain to a reviewer ;) > > (FYI, docShell.setIsApp(Ci.nsIScriptSecurityManager.NO_APP_ID) does *not* > work, even though it looked like it might, and, at face value, sounds more > appropriate. It would work if I supplied a real appId.) > > So, my questions are: > > * Does anyone know a better work-around or solution to this? > * If not, is my work-around a safe and reasonable thing to be doing? > > Thanks, > > Mark > _______________________________________________ > 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
