Re: HTML-based chrome and

On Sat, Feb 27, 2016 at 10:11:19AM +, Benjamin Francis wrote: > On 27 February 2016 at 03:07, Myk Melez wrote: > > > Nevertheless, the more significant factor is that this would be a cultural > > sea change in the Gecko project. > > > > Eh? I didn't realise it was so

Re: HTML-based chrome and

On 2016-02-26 5:52 PM, Fabrice Desré wrote: > On 02/26/2016 02:42 PM, Ehsan Akhgari wrote: > >>> Look at what you need to implement to get the simplest gecko based >>> product that builds with --enable-application=my_great_app and compare >>> it to the same project as an Electron app. >> >> I

Re: HTML-based chrome and

On Mon, Feb 29, 2016 at 2:21 PM, Benjamin Francis wrote: > On 26 February 2016 at 21:26, Ehsan Akhgari > wrote: > > > Without intending to start a shadow discussion on top of what's already > > happening on the internal list (sadly), to answer your

Re: HTML-based chrome and

On 26 February 2016 at 21:26, Ehsan Akhgari wrote: > 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 >

Re: HTML-based chrome and

> With regard to Servo: I’d recommend to request info about the Browser.html > project; it’s something that Paul Rouget bootstrapped, but I haven’t heard > anything about it in a long, long time. Yeah. We've been busy migrating from Gecko to Servo. Now we have a chance to make decisions

Re: HTML-based chrome and

Let me second Justin. I remember a time, not so very long ago, when Gecko powered 4 or 5 non-Mozilla browsers, as well as GPS devices, wysiwyg editors [1], the UX of virus scanners, eBook readers [2], etc, as well as a host of innovative add-ons. At some point, we started deprecating these use

Re: HTML-based chrome and

> On Feb 27, 2016, at 9:43 AM, Mike de Boer wrote: > > It’s also about resources (read: money and other minor details). I think it’s > very cool that Google is able to provide a good foundation for application > frameworks like Electron with Chromium, however they don’t

Re: HTML-based chrome and

I was indeed working on such a project, codenamed ‘Chromeless2’. Then XULRunner got deprecated and that meant that Chromeless2 lost its base building block. I’m passionate about the potential of the platform as a means to bring the web closer to the desktop, but the kind of pragmatism bringing

Re: HTML-based chrome and

Unfortunately, this ship has sailed a long time ago. I didn't really follow at the time, but I'm almost sure that there was a conscious decision that Gecko == Firefoxen. While it makes the development of Firefoxen easier, it pretty much killed the Mozilla Platform, including embedding. These

Re: HTML-based chrome and

On 27 February 2016 at 03:07, Myk Melez wrote: > Nevertheless, the more significant factor is that this would be a cultural > sea change in the Gecko project. > Eh? I didn't realise it was so radical. My entire involvement with Mozilla and Mozilla technologies over the last

Re: HTML-based chrome and

Benjamin Francis 2016 February 26 at 10:16 I like this idea in theory. But I want to understand how it's different from Electron, besides simply using different underlying technology. In other words: what makes it unique that justifies the effort? Why does it even

Re: HTML-based chrome and

h from the existing API. However, the isolated from bug 1238160 is reasonable and a great start. 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. I like this idea in

Re: HTML-based chrome and

> On Feb 26, 2016, at 4:37 PM, Fabrice Desré wrote: > > Look at what you need to implement to get the simplest gecko based > product that builds with --enable-application=my_great_app and compare > it to the same project as an Electron app. There's no surprise why > people

Re: HTML-based chrome and

On 02/26/2016 01:26 PM, Ehsan Akhgari wrote: > 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

Re: HTML-based chrome and

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 ? > But I think a more important piece than webview is the ability t

Re: HTML-based chrome and

> > 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 don't buy

Re: HTML-based chrome and

On 26 February 2016 at 15:21, Paul Rouget wrote: > 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

Re: HTML-based chrome and

On 26 February 2016 at 17:55, Myk Melez wrote: > > I'd like to see this too, if only because is more ergonomic and > easier to distinguish from the existing API. However, > the isolated from bug 1238160 is reasonable and a great > start. > I agree, let's build on that. >

Re: HTML-based chrome and

from bug 1238160 is reasonable and a great start. 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. I like this idea in theory. But I want to understand how it's dif

Re: HTML-based chrome and

Ehsan Akhgari 2016 February 25 at 11:14 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.) Confirmed: I'm definitely *not* planning to

Re: HTML-based chrome and

Benjamin Francis 2016 February 25 at 07:18 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

Re: HTML-based chrome and

ms > 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 par

Re: HTML-based chrome and

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

Re: HTML-based chrome and

I will point out that using Electron's API would mean an easy onramp for developers using Electron today. There are more than a few, and the list is not shrinking. That seems worth > 0. --- Gordon Brander Sr Design Strategist Mozilla ___ dev-platform

Re: HTML-based chrome and

. > 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 abl

Re: HTML-based chrome and

bed above. 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

Re: HTML-based chrome and

On Thu, Feb 25, 2016 at 6:26 PM, Benjamin Francis wrote: > My first priority is a Webview API for Gecko that works without > mozApps on multiple platforms. Is that about coming up with a new and better way to offer privileges (security model)? If so - yes, the Electron

Re: HTML-based chrome and

On Thu, Feb 25, 2016 at 6:32 AM, Benjamin Francis wrote: > Thanks for the heads-up. Will this be available to all chrome privileged > code (i.e. not behind a mozApp permission)? If so, this could be a great > starting point for what I'm describing. The main differences being

Re: HTML-based chrome and

On 25 February 2016 at 16:22, Paul Rouget wrote: > As a user, using or doesn't really > matter. > How would they differ? Same set of JS methods and events? > When Justin Lebar added the mozbrowser attribute to iframes for me in 2011 (see [1] for the whole story) it was meant

Re: HTML-based chrome and

the lines of Electron's 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. As a user, using or doesn't really matter. How would they differ? Same set of JS methods and events? >

Re: HTML-based chrome and

r 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/ser

Re: HTML-based chrome and

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/b

Re: HTML-based chrome and

ertified 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> > befor

HTML-based chrome and

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 element. Kan-Ru previously did a comparison <https://wiki.mozilla.org/WebAPI/BrowserAPI/Common_Subset> of Mozilla's mozBrowser API