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