So there are 2 things here. Browser API change. Sure, what do you propose? I don't care too much about the final syntax. But there are things we can improve in the current API. See https://github.com/browserhtml/browserhtml/issues/639 for some ideas.
A Electron-like project. I don't think there's anybody who would think that having a Electron-compatible tool based on gecko is a bad idea (we will likely go this route with Servo). I'm just not sure we have the resources to work on something like that *today* though. I would suggest to wait a bit until I know if we will indeed go for an Electron-like runtime for Servo (I should know in 2 weeks). If this is the case, it probably won't be too hard to re-implement BrowserWindow with Gecko instead of Servo (but the runtime itself (event loop and modules) would stay in Rust, not need to rewrite that). On Fri, Feb 26, 2016 at 2:15 PM, Benjamin Francis <bfran...@mozilla.com> wrote: > On 25 February 2016 at 23:08, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote: >> >> 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. > > > I really meant the API being gated on mozApps permissions and having mozApp > specific features like events for manifests and web activities, not the > separate mozApp attribute, but those things can certainly be changed. > >> 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. > > > Electron compatibility would be neat, but isn't really what I'm asking for. > As you say, this isn't exposed to the web and doesn't necessarily have to > follow a standard. > >> >> 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 mainly propose the change of syntax because this transition period seems > like an opportunity to make a clean break, get rid of the vendor prefixes > and define a long term, explicitly separate to standard HTML, chrome-only > solution with a cleaner API and without having to worry about backwards > compatibility because the mozBrowser API could exist in parallel until we > phase it out. > > But I think a more important piece than webview is the ability to execute a > Gecko-based user agent with HTML-based chrome without having to run it on > top of the Firefox binary. If we no longer have XULRunner, if mozApps is > phased out and B2G loses platform support we're really running out of > options for how to use Gecko for non-Firefox projects. At what point does > the platform stop being a platform and just becomes Firefox? How are we > promoting innovation if we're effectively forcing alternative user agents to > use WebKit? Unless there is another existing solution I'm missing? > > Ben _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
