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

On 2016-02-25 2:58 PM, Benjamin Francis wrote: > On 25 February 2016 at 19:14, Ehsan Akhgari > wrote: > > 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 >

nsAutoArrayPtr has been removed, please use UniquePtr instead

As the subject says, via bug 1229985. Please also be advised that nsAutoPtr will suffer a similar fate in the not-too-distant future, so writing new code with UniquePtr will make your code better and the removal not take any longer than it needs to. Thanks, -Nathan ___

Re: HTML-based chrome and

On 25 February 2016 at 19:14, Ehsan Akhgari wrote: > 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.) > They are not entirely orthogonal. It seems they will become

Re: HTML-based chrome and

On 2016-02-25 12:26 PM, Benjamin Francis wrote: > The reason for all the moz-prefixed events and attributes was that it was > intended that the Browser API could eventually become a web standard > exposed to web content - but that never happened because we never came up > with a security model for

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 approach sounds like the be

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 the way > you instanti

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 to be a temporary

Re: HTML-based chrome and

On Wed, Feb 24, 2016 at 9:19 PM, Benjamin Francis wrote: > So my proposal is a chrome-only element for Gecko which > would replace the mozApps-only mozBrowser API > , > along the lines of Electron's element >

Re: APNG and Accept-Encoding

On 22/02/16 14:58, Xidorn Quan wrote: > But older Firefoxes go away fairly quickly, so I wouldn't consider > this as a valid reason blocking us moving forward. I'm not sure that's as true as we'd like it to be :-| Gerv ___ dev-platform mailing list dev

Re: HTML-based chrome and

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

Re: HTML-based chrome and

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 s

Re: HTML-based chrome and

Hi Ryan, 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 the way you instantiate a "browser window", and a new chrome-only HTML eleme