On 2016-02-26 8:15 AM, Benjamin Francis wrote: > On 25 February 2016 at 23:08, Ehsan Akhgari <ehsan.akhg...@gmail.com > <mailto: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.
OK. Then it seems much easier to remove the mozApps specific goo from this code rather than doing a <webview> implementation from scratch. I still don't see much value in that. > 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. Good! > 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. I don't think just because we can make a "clean break" now, we should. The time spent here can also be spent on more useful projects. As I explained before, the vendor prefixes don't hurt us in any way here. Other than that, what's the actual incentive to work on <webview>? > 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? Without intending to start a shadow discussion on top of what's already happening on the internal list (sadly), to answer your technical question, the "platform"/Firefox point is a false dichotomy. As an example, you can create a new application target similar to browser, b2g/dev or mobile/android, select that using --enable-application, and start to hack away. That should make it possible to create a non-Firefox project on top of Gecko. You can use an HTML file for browser.startup.homepage, and you can use <iframe mozbrowser> if you need to load Web content. So it's definitely possible to achieve what you want as things stand today. Cheers, Ehsan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
