On 2016-02-25 2:58 PM, Benjamin Francis wrote: > On 25 February 2016 at 19:14, Ehsan Akhgari <ehsan.akhg...@gmail.com > <mailto:ehsan.akhg...@gmail.com>> wrote: > > mozApps and the browser API are orthogonal for the most part. Removing > mozApps doesn't mean that we would remove the mozbrowser API (and AFAIK > that's not what Myk is planning.) > > > They are not entirely orthogonal. It seems they will become less > inter-dependent with bug 1238160 which is a good first step, though that > only applies to desktop.
They're orthogonal in that <iframe mozbrowser> can load something within an "app context", or not, depending on whether you use a mozapp attribute. Bug 1238160 makes it so that you can use the non-app variant on desktop. > > Both. My first priority is a Webview API for Gecko that works without > > mozApps on multiple platforms. But I'd like that to be useful for > multiple > > projects. For it to be useful for a project like Browser.html, Hope, > > Planula and even Firefox I think we need something along the lines of > > BrowserWindow to spawn multiple native windows. > > So is this just a matter of the <webview> syntax versus the <iframe > mozbrowser> syntax? > > > Partly a new chrome-only HTML element and API to allow us to remove the > non-standard vendor-prefixed extensions to the standard HTML iframe > element which have been hanging around for the last four years, but also > a new embedding model along the lines of Electron as I described above. The Electron compatibility aside, this seems to me like replacing one proprietary API for another one. The vendor prefix doesn't hurt us in this case since this API is completely invisible to the Web. So I think it's better to separate out the different things you're asking for here. It seems to me that if we decide that Electron compatibility is desirable, we should implement the webview API, but if we decide that's not valuable, there is little value in implementing webview. > I understand that something the Browser.html team don't like about the > current setup is that you can't spawn multiple windows in the native > window manager because it was built for B2G where it's assumed Gaia will > provide the window manager. More generally I'd like to be able to run > native apps written in HTML-based chrome using Gecko without having to > run them on top of Firefox - like XULRunner but for HTML instead of XUL. > > For the Firefox OS use case I think just making sure the Browser API is > exposed to chrome on Gonk without any mozApp permissions like it's > planned to be on desktop would be a good first step. Maybe that will > already work with bug 1238160? I think that's what that bug is doing, yes. I can't think of why that would work on desktop but not on gonk. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
