Re: HTML-based chrome and

2016-02-26 Thread Myk Melez
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

2016-02-26 Thread 段垚
在 2016/2/27 1:55, Myk Melez 写道: Benjamin Francis 2016 February 26 at 05:15 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

Talos e10s dashboard

2016-02-26 Thread William Lachance
Hey, I wrote up a dashboard for tracking the performance delta between non-e10s and e10s on the Talos tests on nightly: https://treeherder.allizom.org/perf.html#/e10s (sometime next week, https://treeherder.mozilla.org/perf.html#/e10s will work too) Note that the tests are not always

Intent to implement and ship: IDBKeyRange.includes()

2016-02-26 Thread Kyle Huey
*Summary*: This simple API allows one to test whether a given key is included in an IDBKeyRange *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1251498 *Link to standard*: http://w3c.github.io/IndexedDB/#dom-idbkeyrange-includes *Platform coverage*: All platforms *Estimated or target release*:

Re: HTML-based chrome and

2016-02-26 Thread Justin D'Arcangelo
> 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

2016-02-26 Thread Fabrice Desré
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

2016-02-26 Thread Ehsan Akhgari
On 2016-02-26 8:15 AM, Benjamin Francis wrote: > On 25 February 2016 at 23:08, Ehsan Akhgari > wrote: > > They're orthogonal in that can load something within > an "app context", or not, depending on whether you use a mozapp >

Re: HTML-based chrome and

2016-02-26 Thread Paul Rouget
> > 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

2016-02-26 Thread Benjamin Francis
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

2016-02-26 Thread Benjamin Francis
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

2016-02-26 Thread Myk Melez
Benjamin Francis 2016 February 26 at 05:15 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

Re: HTML-based chrome and

2016-02-26 Thread Myk Melez
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

2016-02-26 Thread Myk Melez
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

2016-02-26 Thread Paul Rouget
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

Intent to implement and ship: fetch() referrer and referrer policy APIs

2016-02-26 Thread Ehsan Akhgari
*Summary*: These APIs allow a web page to specify a referrer and a referrer policy when fetching a resource. *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1184549 *Link to standard*: https://fetch.spec.whatwg.org/ *Platform coverage*: All platforms *Estimated or target release*: Firefox 47

Test automation addons and signing

2016-02-26 Thread Andrew Halberstadt
To date, our continuous integration has been setting 'xpinstall.signatures.required=false' to bypass addon signing. But soon, this pref will become obsolete and Firefox will enforce signing no matter what. In preparation, we will begin signing extensions that are used in our test automation. If

Re: HTML-based chrome and

2016-02-26 Thread Benjamin Francis
On 25 February 2016 at 23:08, Ehsan Akhgari wrote: > They're orthogonal in that 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