Hi Vivien, Thanks for the clarifications. Do you have any ideas about how this hypothetical HTML-based browser would be executed long term, rather than running a new Firefox on top of the old Firefox? browser.html currently uses a hack built around a certified mozApp, and the mozBrowser API which is also based around mozApps. I'm looking for a viable post-mozApps solution that could be used by multiple projects.
With the demise of XULRunner it seems the only way to run a Gecko-based project that isn't Firefox is to run it on top of Firefox. That doesn't do much to "promote innovation" and I'm guessing is a major reason projects like Brave are being forced to switch to Webkit/Electron. I'm having to consider the same route for another project as well. Ben On 25 February 2016 at 14:09, Vivien Nicolas <vnico...@mozilla.com> wrote: > Just to make things clearer. > > Planula is not doing exactly what you proposed. It does not tries at all > to emulate Electron, nor provide the same set of APIs. It does not try to > be an HTML app-runtime neither. > > Planula is an HTML browser experiment, running on top of *Firefox Nightly* > (with a very small subset of patches that I need to upload to the repo...). > It does not implies a new permission model, nor new APIs. Though it rely on > mozbrowser iframes. > > Planula aims to be a very small shell around iframe mozbrowser. No > features are really built-in, except tabs and an urlbar. The plan is to > implement *all* features as WebExtensions. In this context a feature means: > a download manager, a bookmark button + a bookmark manager, Firefox Hello, > etc.. > > Basically I would like Planula to be a kind of dedicated sandbox to > migrate Firefox bits out of XUL/XPCOM in an incremental manner. For > example, this kind of sandbox can let us implement a particular feature > (e.g the bookmark button) with pure web technologies, and then try to > backport it to Firefox itself as a self-contained WebExtension. > > This is why Planula re-use as much as possible from Firefox, such as > about: pages, devtools, etc... > > If Planula is ever maintained or used for what it is designed for, one of > the last thing to do would be to convert <xul:browser> to <iframe > mozbrowser>. This will require a bit of plumbing (parts of it beeing > already done in bug 1238160 as jryan mentioned). > > Vivien. > > On Wed, Feb 24, 2016 at 9:19 PM, Benjamin Francis <bfran...@mozilla.com> > wrote: > >> Hi, >> >> I've been thinking about working towards deprecating "Open Web Apps" (aka >> mozApps >> < >> https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/API/Navigator/mozApps >> >) >> in Gecko. >> >> For the most part I think mozApps should eventually be replaced by >> standards-based web apps using Web Manifest, Service Workers etc. I'd love >> to see a standalone display mode for Firefox which supports these web apps >> on desktop and mobile to replace the now defunct web runtime, but that's >> not what this email is about. >> >> For the most privileged pieces of UI like the browser chrome of the >> browser.html project and the Firefox OS system app I think we may need >> another solution. I'd like us to be able to split Gaia >> <https://github.com/mozilla-b2g/gaia> into chrome (the system pieces) and >> standard web content (everything else). (I'd also like to see a lot of the >> current mozApps-only DOM APIs become web services). >> >> - In the past we had XULRunner but this has recently been removed and >> it >> seems the continued use of XUL is being discouraged in favour of HTML. >> - There was an attempt at rebooting the Chromeless project >> <https://github.com/mikedeboer/chromeless2> but it looks like that was >> still based on XULRunner. >> - The browser.html <https://github.com/browserhtml/browserhtml/> >> project >> currently uses Graphene >> < >> https://github.com/browserhtml/browserhtml/wiki/Building-Graphene-%28Gecko-flavor%29 >> >, >> a build of Gecko/Servo which runs locally hosted web content as browser >> chrome, but that's based on certified mozApps and the mozBrowser API. >> >> After chatting with members of the browser.html team I'd like to propose a >> solution inspired by Electron <http://electron.atom.io/> (which they >> already proposed <https://github.com/browserhtml/browserhtml/issues/639> >> before <https://github.com/servo/servo/issues/7379>). This would involve >> a >> new type of HTML-based chrome including a new <webview> element. >> >> Kan-Ru previously did a comparison >> <https://wiki.mozilla.org/WebAPI/BrowserAPI/Common_Subset> of Mozilla's >> mozBrowser API, Google's <webview> and Microsoft's <webview> and I started >> to spec something out <https://github.com/benfrancis/webview/> with a >> view >> to potentially standardising this, but the web lacks the security model >> needed to expose this API and there's currently not much interest in a >> standard. So my proposal is a chrome-only <webview> element for Gecko >> which >> would replace the mozApps-only mozBrowser API >> <https://developer.mozilla.org/en-US/docs/Web/API/Using_the_Browser_API>, >> along the lines of Electron's <webview> element >> <http://electron.atom.io/docs/v0.36.8/api/web-view-tag/>, to allow you to >> safely embed web content in an application with HTML-based chrome. >> >> We could also potentially emulate other parts of Electron's APIs too, see >> their quick start tutorial >> <http://electron.atom.io/docs/v0.36.8/tutorial/quick-start/> to get an >> idea >> of how their embedding works. >> >> Initially this would be used by the browser.html and Firefox OS projects, >> but I think it could be a possible route away from XUL for Firefox in the >> future too. >> >> I've chatted with a few people working on browser.html and Firefox OS >> about >> this, but I'd like to get broader feedback. Vivien told me he's already >> prototyping a similar solution <https://github.com/vingtetun/planula> to >> the same problem so I'd like to kick off some discussion here about which >> direction we should take. >> >> Thanks >> >> Ben >> _______________________________________________ >> 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
