On Fri, Jan 8, 2016 at 4:55 AM, Tim Guan-tin Chien <timdr...@mozilla.com> wrote: > What prevents you from using <xul:browser remote>? Is it because the parent > frame is (X)HTML?
Placing a regular, non-remote <xul:browser> in the HTML page does work. However, <xul:browser remote> does not work in my specific context according to the policy of nsFrameLoader::TryRemoteBrowser()[1] which requires the <xul:browser remote> to be inside chrome docshell, such as the root chrome document. Since I am working from inside a tab, the page is a content docshell (even though I still have chrome access to Components, etc.), so these rules block the remote browser for this case. <iframe mozbrowser remote> is allowed to work in this situation, so that is one big reason I'd like to use it. The other reason I want to use <iframe mozbrowser remote> is that I am using React to manage the content on the page, and creating XUL elements from within an HTML page is AFAIK not supported by React, so you have to do some nasty hacking around to make this work. I'd really prefer to just use HTML elements in my HTML page if I can manage it! > I don't know what prevents browser-element from being enabled on desktop > though -- it's tests are running on desktop, and the actual feature is > hidden behind a permission so we won't expose it to the web content even if > we turn it on. Right, I would assume it works fine on desktop from a technical perspective, since it's used by Mulet and other FxOS simulators that run on desktop. [1]: https://dxr.mozilla.org/mozilla-central/rev/d4213241bb796fdfa7a5ad4f1989e97b44474364/dom/base/nsFrameLoader.cpp#2250 - Ryan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
