Re: HTML-based chrome and

[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 have to be unique? Being able to build a browser using a
browser engine seems like table stakes to me...
There's a significant difference between the minimal effort currently 
required to make Gecko embeddable (at a high cost per embedding) and the 
larger, ongoing effort that would be required to build and maintain an 
application development platform like Electron.


Moreover, there's an opportunity cost: time spent developing that 
platform would be time not spent enhancing Gecko's Web platform 
implementation.


Nevertheless, the more significant factor is that this would be a 
cultural sea change in the Gecko project. Even with engineers who were 
willing and able to sign up to do the work (and who would otherwise not 
hack on Gecko, minimizing the opportunity cost), it would still be a 
challenge to make Gecko-as-platform a fundamental part of the way Gecko 
is developed. The small matter of programming is the least of our concerns.


Which doesn't mean I think it's a bad idea. To the contrary, a 
successful app platform based on Gecko would indirectly benefit Gecko's 
Web platform goals (and Firefox) by expanding the community of 
contributors to the project. But an unsuccessful effort would do more 
harm than good.


So I still want to understand how "Gecktron" would be different, and why 
a developer (Mozillian or otherwise) should prefer it to Electron. Why 
not use Electron for your project?


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML-based chrome and

[段垚]

在 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 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'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.


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 
different from Electron, besides simply using different underlying 
technology. In other words: what makes it unique that justifies the 
effort? Is there something that Gecko can provide that Chromium cannot 
(or is unlikely to)? Are there parts of the Electron stack that are 
encumbered in some way? Are there architectural choices that make 
Electron unsuitable or suboptimal for valuable use cases?


One of our project switched from Electron to XULRunner about half a year 
ago, because:


* MathML. Our project is a slide editor for education, so MathML is 
important. Google rejected to implement MathML so Electron and NW.js are 
out of luck.
  We tried to use mathml.css in Electron but you know the result is 
suboptimal. MathJax is suitable for presenting but not for editing.


* Auto update. We found that build-in auto updating of XULRunner is easy 
to use and robust. Electron and NW.js has no such mature solution yet.


* Windows XP support. Our project has to support XP for an extended 
time, however Chromium will drop XP support this year, and Electron 
never runs on XP.


Unfortunately, we might be force to switch back to Electron or NW.js in 
future because XULRunner was remove from Mozilla's code base and there 
is no foreseen alternative.
Our company is small and has not enough resource to maitain XULRunner by 
ourselves (We even don't known whether it is tecnically feasible). A 
HTML-based "XULRunner successor" is definitely interesting to us!




(You can argue that developers having two options is by itself 
beneficial. And I agree, in general. But I'm not yet convinced that we 
should therefore invest the effort to build the second option.)



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?
That point is well in the past, as Gecko development post-Netscape has 
focused on the Web platform and integration with Firefox. Other uses, 
like XULRunner and embedding in native apps, have been second-class 
citizens, at best.



How are we
promoting innovation if we're effectively forcing alternative user 
agents

to use WebKit?
Mozilla's mission is to promote "openness, innovation & opportunity on 
the Web."  Mitchell clarified in 2007 that Mozilla's key platform is 
the Open Web 
.


I happen to think that making Gecko a great platform for building 
products like (but not limited to) Firefox indirectly benefits that 
mission. But doing so would still be in service to that mission, a way 
to help fulfill it, and not the actual mission itself.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Talos e10s dashboard

[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 measuring exactly the same thing, so 
be careful of making naive judgements based on this data (see 
https://bugzilla.mozilla.org/show_bug.cgi?id=1250620 for more details). 
Still, I thought this might be generally interesting so decided to post 
a link to it here.


Will
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: IDBKeyRange.includes()

[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*: Firefox 47
*Preference behind which this will be implemented*: No preference
Do other browser engines implement this? Blink is planning to implement and
ship this per discussions with Joshua Bell.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML-based chrome and

[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 are not using gecko here. Just having to build a custom gecko for
> N platforms is big drawback. Oh, and you're obviously Tier 100 when you
> do that, so you have to chase gecko's changes, sec fixes etc.
> 
> It's not whether it's doable (especially not whether a gecko engineer
> can do it) but if it's a reasonable tool for others to use. Gecko is not
> one unfortunately.

+1

Do we even have documentation on how to create a *new* application via 
`--enable-application`? Most documentation on MDN that I’ve found only 
describes how to use that flag to select an existing application (e.g. firefox, 
thunderbird).

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML-based chrome and

[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 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  if you
> need to load Web content.  So it's definitely possible to achieve what
> you want as things stand today.

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 are not using gecko here. Just having to build a custom gecko for
N platforms is big drawback. Oh, and you're obviously Tier 100 when you
do that, so you have to chase gecko's changes, sec fixes etc.

It's not whether it's doable (especially not whether a gecko engineer
can do it) but if it's a reasonable tool for others to use. Gecko is not
one unfortunately.

-- 
Fabrice Desré
Connected Devices
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML-based chrome and

[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
> 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  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 ?

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

Re: HTML-based chrome and

[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 that. We just cancelled a bunch of projects and we still don't 
> have the resources? If that is really true then maybe we should be hiring 
> people.

Whatever happens, I really recommend that we build this on top of
Spidermonkey + Rust. We can then have 2 separate implementations of
BrowserWindow for Servo and Gecko.


On Fri, Feb 26, 2016 at 7:16 PM, Benjamin Francis  wrote:
> 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.
>
>>
>> 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 have to be unique? Being able to build a browser using a
> browser engine seems like table stakes to me...
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML-based chrome and

[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 https://github.com/browserhtml/browserhtml/issues/639
> for some ideas.
>

OK, let's discuss those specifics off-list.

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 that. We just cancelled a bunch of projects and we still don't
have the resources? If that is really true then maybe we should be hiring
people.

But I'm happy to help in any way I can and there are quite a few people in
Connected Devices who have some spare cycles right now...

Ben
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML-based chrome and

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


> 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 have to be unique? Being able to build a browser using a
browser engine seems like table stakes to me...
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML-based chrome and

[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
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'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.



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 different 
from Electron, besides simply using different underlying technology. In 
other words: what makes it unique that justifies the effort? Is there 
something that Gecko can provide that Chromium cannot (or is unlikely 
to)? Are there parts of the Electron stack that are encumbered in some 
way? Are there architectural choices that make Electron unsuitable or 
suboptimal for valuable use cases?


(You can argue that developers having two options is by itself 
beneficial. And I agree, in general. But I'm not yet convinced that we 
should therefore invest the effort to build the second option.)



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?
That point is well in the past, as Gecko development post-Netscape has 
focused on the Web platform and integration with Firefox.  Other uses, 
like XULRunner and embedding in native apps, have been second-class 
citizens, at best.



How are we
promoting innovation if we're effectively forcing alternative user agents
to use WebKit?
Mozilla's mission is to promote "openness, innovation & opportunity on 
the Web."  Mitchell clarified in 2007 that Mozilla's key platform is the 
Open Web 
.


I happen to think that making Gecko a great platform for building 
products like (but not limited to) Firefox indirectly benefits that 
mission. But doing so would still be in service to that mission, a way 
to help fulfill it, and not the actual mission itself.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML-based chrome and

[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 remove the mozbrowser API!

-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML-based chrome and

[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 Brave are being forced to switch to Webkit/Electron.
I expect that's true in general, although for Brave in particular, 
Brendan tweeted, "Started w/ Graphene/Gecko but needed full sandboxing, 
MDI,  Also: Chrome web compat :-(." 
. And the 
Brave FAQ states, "We did a careful head-to-head comparison and by every 
measure, Electron/chromium won" .


So the relative support for embedding doesn't appear to be the major driver.

-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML-based chrome and

[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 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 would
suggest to wait a bit until I know if we will indeed go for an
Electron-like runtime for Servo (I should know in 2 weeks). If this is
the case, it probably won't be too hard to re-implement BrowserWindow
with Gecko instead of Servo (but the runtime itself (event loop and
modules) would stay in Rust, not need to rewrite that).


On Fri, Feb 26, 2016 at 2:15 PM, 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
>> 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

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

[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
*Preference behind which this will be implemented*: No preference
*DevTools bug*: This doesn't require explicit devtools support as it's
about implementing a few DOM APIs.
Do other browser engines implement this? Blink ships the referrer API, and
they plan to implement and ship the referrer policy API.  Both our
implementations are tested against the web-platform-tests for this feature.

Since this is a small scoped feature, I'm planning to land the patches to
implement it fully and let it ride the trains in Firefox 47.

Cheers,
-- 
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Test automation addons and signing

[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 you maintain one of these addons, it means you will
be required to re-sign it everytime a change is made. For more
information on what this means, how to sign addons or how to bypass
signing completely, see the following document:
https://wiki.mozilla.org/EngineeringProductivity/HowTo/SignExtensions

Let me know if you have any questions or concerns,
Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML-based chrome and

[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 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