Re: HTML-based chrome and

[Mike Hommey]

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 radical.
> 
> My entire involvement with Mozilla and Mozilla technologies over the last
> 10 years has been building projects on top of XULRunner, Chromeless and
> B2G/Graphene. This was something which was possible until literally the
> last month when B2G became tier 3 and XULRunner was removed from the
> codebase.

Note that technically, XULRunner was only removed as an independent
product. It is still possible to run XULRunner applications with...
Firefox. (just use `firefox -app /path/to/application.ini` instead of
`xulrunner /path/to/application.ini`)

Mike
___
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 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 never said that it is as easy as Electron, did I?  :-)  Ben explicitly
>> said he doesn't care for Electron compat, hence my suggestion.
> 
> But your suggestion is not a reasonable alternative for people looking
> at an alternative to Electron, even with no api compat.

Yeah, that's true.  You'll have to forgive me but this thread started as
a request for the  API, it's sometimes very difficult to
reverse engineer what problems people are trying to solve based on the
solutions they propose.  :-)

>>> 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.
>>
>> Who are these "others"?  If you are talking about a random person who
>> wants to create a new desktop app, then yes, that solution is far from
>> desirable.  If you're talking about a Mozilla engineer wanting to create
>> a new product on top of Gecko that is completely separate from Firefox,
>> this is the way to do it.  If you're implying that in order to satisfy
>> the second use case we need to solve the first one, then I'm not sure if
>> I agree.
> 
> I say that we should focus more on solving the first use case, since the
> second one is ... not really a problem for a Mozilla engineer and
> happens rarely. But if your point is that we should not care about 3rd
> party devs that want to use gecko, I'm puzzled - that seems like major
> shortsightedness coming from a 'platform' team. If I misunderstood, my
> apologies.

Please note that this is not about what _I_ want as someone on the
platform team.  I personally think that in hindsight, it was a mistake
for us to miss the runtime embedding ship at least twice (once with
WebKit and now with Chromium Embedding Framework).  For the last few
years, our strategy for investing in Gecko has mostly been as a vehicle
for investing in the end user facing products that we build, so a
*large* portion of the platform team have been working on things
intended to support Firefox OS and now Firefox.

The cost of building and maintaining a successful product based around
Gecko is quite significant, and I'm afraid that we just don't currently
have enough investment in Gecko in order to be able to sustain this.
Therefore, effectively when someone asks "can we build something like
Electron on top of Gecko", they're asking for a whole new set of
investments from a team who is working hard to just keep up with the day
to day activities already promised to the product teams.

In this sense, I agree with Myk.  This is not a technical issue, the ask
here is to shift what we invest in as an organization, and I personally
agree that it would be nice to have that (and have more investment in
Gecko.)  I just don't have a good answer, since promising to build
what's being asked here with our current organization-wide investments
is dishonest and will just set people up for failure.  But it also pains
me to have to recommend competing Web platform implementations for this
use case...  :(
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML-based chrome and

[Vivien Nicolas]

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 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.
> >
>
> OK, so to follow this logic in the case of B2G, your recommended solution
> would be to transform /b2g/chrome/content/shell.html [1] into a replacement
> for Gaia's system app and land that code directly in mozilla-central?
>
> That could potentially work for the B2G use case and would remove an entire
> layer from the architecture which sounds great. But it would mean putting
> that code in mozilla-central rather than a completely separate project on
> GitHub.
>
>

If you look at Planula source code you will see that it basically runs on
top of Firefox Nightly, replacing browser.xul by a custom HTML file, using
 to load web content. Planula is also a separate github
project.

At the end it's not perfect, nor the most ideal situation, but at least you
can start to prototype a new browser, or anything else, without having to
rebuild m-c every time. (hint: you can basically use F5 to refresh the
whole UI).

That said, if you want to build a full featured web browser, with only HTML
technologies, you may have to deal with some internal details of Gecko. You
can bypass some of it with the right set of hand-crafted addons (look at
config/profile/extensions/zyzzyva). Some others details will force part of
you architecture to be exactly how Gecko expects the front-end to be
formatted (e.g having an iframe with the type content-primary in your
startup page, or exposing a gBrowser global in some cases...) but you can
really go very far if you want to build a browser and follow what Alexandre
and myself have done with Planula.

You may also needs a few set of patches to apply to Gecko to allow your
front-end to load the devtools, or use about: pages. But most of those are
pretty small and scoped patches that should not be too hard to uplift
upstream.

Again Planula is mostly designed to explore part of Firefox that can be
replaced without the help of XUL/XPCOM and see how much can be really
achieved with such technologies that trying to simulate a full-featured
Electron clone (which would be cool but seems a lot of work with a lot of
resources dedicated to it from various teams, and seems unrealistic with
the current focus from MoCo).

While Planula goal is to try to land some parts of it into browser/ and
toolkit/, you can already start to prototype something right away without
the need to hit m-c.

Vivien.


> Ben
>
> 1.
>
> https://dxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.html
> ___
> 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

Re: HTML-based chrome and

[Benjamin Francis]

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

OK, so to follow this logic in the case of B2G, your recommended solution
would be to transform /b2g/chrome/content/shell.html [1] into a replacement
for Gaia's system app and land that code directly in mozilla-central?

That could potentially work for the B2G use case and would remove an entire
layer from the architecture which sounds great. But it would mean putting
that code in mozilla-central rather than a completely separate project on
GitHub.

Ben

1.
https://dxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.html
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML-based chrome and

[Paul Rouget]

> 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 without code legacy or
compatibility issues, and we will most likely implement an
Electron-compatible runtime (Rust + Spidermonkey + Servo).

What we really really want to avoid with Browser.html is to end up in
the monoculture situation David is talking about. So instead of
inventing something new, we will work on and with the existing
established opensource projects (Electron and React).


On Sun, Feb 28, 2016 at 2:47 PM, David Rajchenbach-Teller
 wrote:
> 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
> cases for Gecko, because they were not the Web Platform.
>
> In terms of our long-term goals, this makes entire sense. We encouraged
> developers to move from an open-source yet non-standardized library that
> we knew we could not maintain forever (the Mozilla Platform, which for
> some reason we sometimes equate with XUL) towards the standardized,
> interoperable Web Platform.
>
> This strategy was based on the assumption that our preferences mattered.
> Unfortunately for us, history has shown that the world doesn't care all
> that much about what browser vendors want.
>
> In hindsight, I believe that, by turning Gecko into a monoculture, we
> have done to ourselves what we fear will happen to the web if it turns
> into a Chromium monoculture. We have gained some development agility,
> but we have lost most of the innovations (and innovators) that were not
> already on our roadmap. We have also lost the drive to provide clean
> platform-level APIs, and separation of concerns between libraries, and
> testing and feedback, all of which can only hurt our codebase.
>
> Somewhere else in the world, the ease of embedding first WebKit and now
> Chromium (not Blink afaict) have considerably increased their
> hackerbase. I haven't checked, but I suspect that this is only
> beneficial at all levels. Speaking only for myself, if I were to enter
> the field today with the same kind of technological needs I had 15 years
> ago, I would head towards Chromium without giving it a second thought. I
> find it a bit sad that my present self is somehow working against my
> past self.
>
> Now, in Internet time, these choices were made generations ago, and I
> suspect that it is too late to change them for Gecko, and that we need
> to live with them. It would probably be possible to man and push forward
> XULRunner or a variant thereof, but that would most likely be too
> expensive, too little, too late.
>
> Again, hindsight is 20:20. I believe that the choices we made years ago
> were wrong. I also suspect that changing the course of Gecko now would
> be too expensive, too little, too late.
>
> On the other hand, I believe that we should draw lessons from the past,
> for our younger projects: Rust, Servo, Connected Devices, ...
>
> CD are too young to be able to judge, but Rust and Servo have proved
> very open to innovation so far, which is great. Thanks to this, both
> have a chance of becoming the tool of choice in domains in which Mozilla
> doesn't dabble. Again, the benefits to the projects would be immeasurable.
>
> Anyway, this starts to sound like a blog post (and hopefully not too
> much like a rant), so I guess you'll see a refined version of this
> message on Planet Mozilla one of these days.
>
> Cheers,
>  David
>
> [1] Yes, Glazou, I know that you're still active with Bluegriffon :)
> [2] That was how I got started with Gecko, incidentally.
>
> On 28/02/16 06:26, Justin D'Arcangelo wrote:
>> The question "what do I think we should do for the web of tomorrow?” is
>> certainly important for us to ask. However, one of the reasons that so
>> many have been interested in an “embedded Gecko” solution like
>> Electron/NW.js/whatever is so that we *can* begin experimenting with new
>> things that may be a part of “the web of tomorrow”. It is simply not
>> efficient or practical for many of us to spend a significant amount of
>> time prototyping experimental features *directly* within Gecko.
>> Especially when, if you look to other solutions like Electron or NW.js,
>> the same thing can be achieved in a fraction of the time. If there is no
>> easy way to reuse Gecko outside of Firefox proper, then it is not as
>> much of a platform as it is a part of a product. Before I get criticized
>> for that last sentence, I should clarify that yes, Firefox *is* a
>> platform in the way that the web and all browsers are a platform.
>> However, if Gecko cannot trivially exist in a different con

Re: HTML-based chrome and

[David Rajchenbach-Teller]

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
cases for Gecko, because they were not the Web Platform.

In terms of our long-term goals, this makes entire sense. We encouraged
developers to move from an open-source yet non-standardized library that
we knew we could not maintain forever (the Mozilla Platform, which for
some reason we sometimes equate with XUL) towards the standardized,
interoperable Web Platform.

This strategy was based on the assumption that our preferences mattered.
Unfortunately for us, history has shown that the world doesn't care all
that much about what browser vendors want.

In hindsight, I believe that, by turning Gecko into a monoculture, we
have done to ourselves what we fear will happen to the web if it turns
into a Chromium monoculture. We have gained some development agility,
but we have lost most of the innovations (and innovators) that were not
already on our roadmap. We have also lost the drive to provide clean
platform-level APIs, and separation of concerns between libraries, and
testing and feedback, all of which can only hurt our codebase.

Somewhere else in the world, the ease of embedding first WebKit and now
Chromium (not Blink afaict) have considerably increased their
hackerbase. I haven't checked, but I suspect that this is only
beneficial at all levels. Speaking only for myself, if I were to enter
the field today with the same kind of technological needs I had 15 years
ago, I would head towards Chromium without giving it a second thought. I
find it a bit sad that my present self is somehow working against my
past self.

Now, in Internet time, these choices were made generations ago, and I
suspect that it is too late to change them for Gecko, and that we need
to live with them. It would probably be possible to man and push forward
XULRunner or a variant thereof, but that would most likely be too
expensive, too little, too late.

Again, hindsight is 20:20. I believe that the choices we made years ago
were wrong. I also suspect that changing the course of Gecko now would
be too expensive, too little, too late.

On the other hand, I believe that we should draw lessons from the past,
for our younger projects: Rust, Servo, Connected Devices, ...

CD are too young to be able to judge, but Rust and Servo have proved
very open to innovation so far, which is great. Thanks to this, both
have a chance of becoming the tool of choice in domains in which Mozilla
doesn't dabble. Again, the benefits to the projects would be immeasurable.

Anyway, this starts to sound like a blog post (and hopefully not too
much like a rant), so I guess you'll see a refined version of this
message on Planet Mozilla one of these days.

Cheers,
 David

[1] Yes, Glazou, I know that you're still active with Bluegriffon :)
[2] That was how I got started with Gecko, incidentally.

On 28/02/16 06:26, Justin D'Arcangelo wrote:
> The question "what do I think we should do for the web of tomorrow?” is
> certainly important for us to ask. However, one of the reasons that so
> many have been interested in an “embedded Gecko” solution like
> Electron/NW.js/whatever is so that we *can* begin experimenting with new
> things that may be a part of “the web of tomorrow”. It is simply not
> efficient or practical for many of us to spend a significant amount of
> time prototyping experimental features *directly* within Gecko.
> Especially when, if you look to other solutions like Electron or NW.js,
> the same thing can be achieved in a fraction of the time. If there is no
> easy way to reuse Gecko outside of Firefox proper, then it is not as
> much of a platform as it is a part of a product. Before I get criticized
> for that last sentence, I should clarify that yes, Firefox *is* a
> platform in the way that the web and all browsers are a platform.
> However, if Gecko cannot trivially exist in a different context outside
> of Firefox, then *Gecko* itself is not a platform.
> 
> The fact that WebKit/Chromium is embedded in a variety of different
> applications that are not web browsers means that it is also perceived
> by many as a platform in and of itself. However, this does not mean that
> these applications do not make use of or benefit the web. With Electron
> or NW.js, a developer can build cross-platform native applications using
> web technologies that integrate deeply with various OSes.
> Hypothetically, in cases where several Electron apps might use a
> specific NPM package for some sort of OS integration that is not
> available to ordinary web content, this may highlight gaps in the web
> platform that we should probably fill.
> 
>> I wouldn’t feel any shame to use Electron for my next desktop app or
>> prototype thing. You can’t really build a browser with it (pl

Re: HTML-based chrome and

[Justin D'Arcangelo]

> 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 provide it to make 
> Electron possible! They have their own consumer targeted products like 
> ChromeOS/ ChromeBook that they need to support on the marketplace. And it 
> takes a lot of resources to make that work.
> Our resources are quite modest. My own resources are also quite modest; if I 
> had all the time in the world, I’d keep XULRunner alive single-handedly.
> 
> Lately I find myself believing more and more in today’s Mozilla: what do I 
> think we should do for the web of tomorrow? If we want to really deprecate 
> XUL, what pieces of the puzzle do we currently miss?
> 

The question "what do I think we should do for the web of tomorrow?” is 
certainly important for us to ask. However, one of the reasons that so many 
have been interested in an “embedded Gecko” solution like 
Electron/NW.js/whatever is so that we *can* begin experimenting with new things 
that may be a part of “the web of tomorrow”. It is simply not efficient or 
practical for many of us to spend a significant amount of time prototyping 
experimental features *directly* within Gecko. Especially when, if you look to 
other solutions like Electron or NW.js, the same thing can be achieved in a 
fraction of the time. If there is no easy way to reuse Gecko outside of Firefox 
proper, then it is not as much of a platform as it is a part of a product. 
Before I get criticized for that last sentence, I should clarify that yes, 
Firefox *is* a platform in the way that the web and all browsers are a 
platform. However, if Gecko cannot trivially exist in a different context 
outside of Firefox, then *Gecko* itself is not a platform.

The fact that WebKit/Chromium is embedded in a variety of different 
applications that are not web browsers means that it is also perceived by many 
as a platform in and of itself. However, this does not mean that these 
applications do not make use of or benefit the web. With Electron or NW.js, a 
developer can build cross-platform native applications using web technologies 
that integrate deeply with various OSes. Hypothetically, in cases where several 
Electron apps might use a specific NPM package for some sort of OS integration 
that is not available to ordinary web content, this may highlight gaps in the 
web platform that we should probably fill.

> I wouldn’t feel any shame to use Electron for my next desktop app or 
> prototype thing. You can’t really build a browser with it (please, spare me 
> the Brave bravado, it’s saddeningly mediocre), but any other thing would 
> probably be fine.

I believe many of us *will* start doing this since there doesn’t seem to be 
another option. However, I feel that it will reflect poorly on us if we start 
prototyping our ideas with a web platform implementation that we do not control.

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

Re: HTML-based chrome and

[Mike de Boer]

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 change with the tech 
we currently have is not part of Mozilla today.
Today it’s about the other side of the spectrum: where will the web be 
tomorrow? What can we do to get there first, in pole position?
Discussing these topics is interesting and allows more rigorous decision 
making, like cancelling projects, much simpler to reason about. ‘Great or dead’ 
is not hard to understand, especially given the mindset that we strive to excel 
at moving the web forward.

Hence, focus shifts more to usual suspects: (future) web standards, emerging 
technology (VR, IoT, etc) and stabilising the core (Rust, e10s). It’s arguably 
more interesting to work on these type of projects instead of the archaic 
desktop.
Part of this is an image problem, as in Firefox Desktop is generally not deemed 
as sexy stuff to write code for; many developers - also within Mozilla - when 
they read ‘Firefox Desktop’, they see ‘XUL’, 
‘Components.interfaces.nsIOMGIDontWantToBeHere’, ‘browser.js: 8000 LoC’ and 
recently ‘Electrolysis, electrolsys, electrol, electro-something’.
Funny, isn’t it, that our most successful project ever is not sexy to work on? 
Personally, I see so many areas that I can have an impact on with my work that 
it startles me over and over. But I’m weird that way.

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 provide it to make 
Electron possible! They have their own consumer targeted products like 
ChromeOS/ ChromeBook that they need to support on the marketplace. And it takes 
a lot of resources to make that work.
Our resources are quite modest. My own resources are also quite modest; if I 
had all the time in the world, I’d keep XULRunner alive single-handedly.

Lately I find myself believing more and more in today’s Mozilla: what do I 
think we should do for the web of tomorrow? If we want to really deprecate XUL, 
what pieces of the puzzle do we currently miss?

I wouldn’t feel any shame to use Electron for my next desktop app or prototype 
thing. You can’t really build a browser with it (please, spare me the Brave 
bravado, it’s saddeningly mediocre), but any other thing would probably be fine.
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.

I hope this helps,

Mike.


> On 27 Feb 2016, at 14:04, David Rajchenbach-Teller  
> wrote:
> 
> 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 days, any mozEffort towards having a platform/embedding come
> around Servo.
> 
> Cheers,
> David
> 
> P.S.: I may be exaggerating a bit, I seem to remember that Mike De Boer
> was working on his own on a project for developing applications with
> Node + Gecko.
> 
> On 27/02/16 11:11, Benjamin Francis wrote:
>> I've been kind of taken aback at the lengths the platform team is willing
>> to go to to prevent the platform being used by anyone. If Mozilla limits
>> itself to just being about Firefox then I think we really will be going the
>> way of the dinosaur.
>> 
>> Ben
>> ___
>> 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

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

Re: HTML-based chrome and

[David Rajchenbach-Teller]

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 days, any mozEffort towards having a platform/embedding come
around Servo.

Cheers,
 David

P.S.: I may be exaggerating a bit, I seem to remember that Mike De Boer
was working on his own on a project for developing applications with
Node + Gecko.

On 27/02/16 11:11, Benjamin Francis wrote:
> I've been kind of taken aback at the lengths the platform team is willing
> to go to to prevent the platform being used by anyone. If Mozilla limits
> itself to just being about Firefox then I think we really will be going the
> way of the dinosaur.
> 
> Ben
> ___
> 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

Re: HTML-based chrome and

[Benjamin Francis]

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
10 years has been building projects on top of XULRunner, Chromeless and
B2G/Graphene. This was something which was possible until literally the
last month when B2G became tier 3 and XULRunner was removed from the
codebase. I'm fine with losing XUL, all I'm really asking for is a simple
way to bootstrap an HTML-based project with chrome privileges so I can
continue to do what I was hired to do, which is innovating on the front end.

Why not use Electron for your project?
>

That does seem like a more attractive option than forking mozilla-central
for every new project I work on, which I think is what you're suggesting.

I've been kind of taken aback at the lengths the platform team is willing
to go to to prevent the platform being used by anyone. If Mozilla limits
itself to just being about Firefox then I think we really will be going the
way of the dinosaur.

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

Re: HTML-based chrome and

[Fabrice Desré]

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 never said that it is as easy as Electron, did I?  :-)  Ben explicitly
> said he doesn't care for Electron compat, hence my suggestion.

But your suggestion is not a reasonable alternative for people looking
at an alternative to Electron, even with no api compat.

>> 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.
> 
> Who are these "others"?  If you are talking about a random person who
> wants to create a new desktop app, then yes, that solution is far from
> desirable.  If you're talking about a Mozilla engineer wanting to create
> a new product on top of Gecko that is completely separate from Firefox,
> this is the way to do it.  If you're implying that in order to satisfy
> the second use case we need to solve the first one, then I'm not sure if
> I agree.

I say that we should focus more on solving the first use case, since the
second one is ... not really a problem for a Mozilla engineer and
happens rarely. But if your point is that we should not care about 3rd
party devs that want to use gecko, I'm puzzled - that seems like major
shortsightedness coming from a 'platform' team. If I misunderstood, my
apologies.

-- 
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 4:37 PM, Fabrice Desré wrote:
> 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.

I never said that it is as easy as Electron, did I?  :-)  Ben explicitly
said he doesn't care for Electron compat, hence my suggestion.

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

Who are these "others"?  If you are talking about a random person who
wants to create a new desktop app, then yes, that solution is far from
desirable.  If you're talking about a Mozilla engineer wanting to create
a new product on top of Gecko that is completely separate from Firefox,
this is the way to do it.  If you're implying that in order to satisfy
the second use case we need to solve the first one, then I'm not sure if
I agree.

Cheers,
Ehsan
___
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, &c. 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

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

Re: HTML-based chrome and

[Gordon Brander]

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 mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML-based chrome and

[Ehsan Akhgari]

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
> that's not what Myk is planning.)
> 
> 
> They are not entirely orthogonal. It seems they will become less
> inter-dependent with bug 1238160 which is a good first step, though that
> only applies to desktop.

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.

> > Both. My first priority is a Webview API for Gecko that works without
> > mozApps on multiple platforms. But I'd like that to be useful for 
> multiple
> > projects. For it to be useful for a project like Browser.html, Hope,
> > Planula and even Firefox I think we need something along the lines of
> > BrowserWindow to spawn multiple native windows.
> 
> So is this just a matter of the  syntax versus the  mozbrowser> syntax?
> 
> 
> Partly a new chrome-only HTML element and API to allow us to remove the
> non-standard vendor-prefixed extensions to the standard HTML iframe
> element which have been hanging around for the last four years, but also
> a new embedding model along the lines of Electron as I described above.

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.

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 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 apps written in HTML-based chrome using Gecko without having to
> run them on top of Firefox - like XULRunner but for HTML instead of XUL.
> 
> For the Firefox OS use case I think just making sure the Browser API is
> exposed to chrome on Gonk without any mozApp permissions like it's
> planned to be on desktop would be a good first step. Maybe that will
> already work with bug 1238160?

I think that's what that bug is doing, yes.  I can't think of why that
would work on desktop but not on gonk.
___
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 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 less
inter-dependent with bug 1238160 which is a good first step, though that
only applies to desktop.

> Both. My first priority is a Webview API for Gecko that works without
> > mozApps on multiple platforms. But I'd like that to be useful for
> multiple
> > projects. For it to be useful for a project like Browser.html, Hope,
> > Planula and even Firefox I think we need something along the lines of
> > BrowserWindow to spawn multiple native windows.
>
> So is this just a matter of the  syntax versus the  mozbrowser> syntax?
>

Partly a new chrome-only HTML element and API to allow us to remove the
non-standard vendor-prefixed extensions to the standard HTML iframe element
which have been hanging around for the last four years, but also a new
embedding model along the lines of Electron as I described 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 apps
written in HTML-based chrome using Gecko without having to run them on top
of Firefox - like XULRunner but for HTML instead of XUL.

For the Firefox OS use case I think just making sure the Browser API is
exposed to chrome on Gonk without any mozApp permissions like it's planned
to be on desktop would be a good first step. Maybe that will already work
with bug 1238160?

Ben
___
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-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 mozApps fit for that purpose. If we remove
> mozApps from Gecko I think we'll still want something like the Browser API,

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

> Both. My first priority is a Webview API for Gecko that works without
> mozApps on multiple platforms. But I'd like that to be useful for multiple
> projects. For it to be useful for a project like Browser.html, Hope,
> Planula and even Firefox I think we need something along the lines of
> BrowserWindow to spawn multiple native windows.

So is this just a matter of the  syntax versus the  syntax?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML-based chrome and

[Paul Rouget]

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 best way to do it.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML-based chrome and

[J. Ryan Stinnett]

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 instantiate a "browser window", and a new chrome-only HTML element with
> a new name and a cleaner API (the current mozBrowser extension to iframes is
> a bit of a mess).

Yes, it's available to any chrome documents. It is gated on the
"browser" permission from mozApps, but the permission manager allows
all permissions for chrome documents by default, so as a result it's
always available in chrome docs. If we removed all the mozApps stuff
at some point, it would just reduce to checking if the document is
chrome for this case.

> Also, is this restricted to desktop or could it be exposed on other
> platforms too (i.e. Android/Gonk)?

The current bug only exposes it on desktop. I would assume it can be
made to work on Android since we had b2gdroid there, and Gonk since
Firefox OS used it. However, I haven't tried these combinations
explicitly as part of the bug I mentioned.

- Ryan
___
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 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 solution, I'm
trying to figure out a more future proof solution which is less tied to
mozApps and mozApps-only functionality (e.g. mozbrowsermanifestchange [2]
and mozbrowseractivitydone [3], the separate data jars etc.).

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 mozApps fit for that purpose. If we remove
mozApps from Gecko I think we'll still want something like the Browser API,
but if it's only exposed to chrome then I think it makes sense to create a
completely separate chrome-only HTML element (a bit like xul:browser) and
take the opportunity to clean up the API. I imagine a new Webview API would
look a lot like the current Browser API, but with less vendor prefixes and
less issues (e.g. Some of those listed at [4]).

These are 2 different things.
>
> This is about BrowserWindow, which is a different beast.
>
> BrowserWindow is a window that loads a HTML page. That HTML page can
> use .
> Electron is basically a way to start and handle privileged HTML
> windows. It does what shell.js does (but headless!).
>
> For Servo, what i'd like us to do is:
> - have a JS runtime à-la nodejs, in Rust (with rust modules)
> - one of the rust module will be BrowserWindow, that will spawn a
> servo window that would allow the use of webviews
> - implement webview/mozbrowser within Servo
>
> I describe that here: https://github.com/servo/servo/issues/7379 and
> it's basically a subset of Electron, but with Spidermonkey, Servo, and
> Rust.
>
> If you want the same thing with Gecko, you'd need to be able to spawn
> gecko windows from a xpcshell-like tool (with an event loop that is
> not tied to a window). A headless JS script should be the entry point,
> not a window (shell.html).
>
> I'm almost certain that the Electron approach is what should be done
> if one wants to build desktop applications with web technologies. And
> if such application is a browser, the web engine needs to support
> webviews.
>
> An interesting issue we have today is system XHR. We are not sure we
> want to pollute the existing XHR code in Servo to add special
> behaviors. But in the headless JS, because it's a node-like
> environment (no need to think about security or web specifications,
> http://tola.me.uk/blog/2014/08/07/building-the-firefox-browser-for-firefox-os/
> it's part of the app, like shell.html), we could imagine using any
> crates.io's packages exposed in the JS world, and implement
> cross-origin http requests. We don't want to mix both worlds. The
> browser itself (the top level window, above the webviews) can
> communicate with the headless JS via message passing.
>
> Basically,  is the Browser API, Electron is nodejs +
> BrowserWindow that spawn webkit windows.
>
> --
>
> So what do you want to do here?
> You'd like to redesign the Browser API?
> Or propose a way to create apps with Gecko with a Electron-like project?
> Both?
>

Both. My first priority is a Webview API for Gecko that works without
mozApps on multiple platforms. But I'd like that to be useful for multiple
projects. For it to be useful for a project like Browser.html, Hope,
Planula and even Firefox I think we need something along the lines of
BrowserWindow to spawn multiple native windows.

I don't have a good answer to cross-origin XHR/fetch, but that is
definitely something which is needed to build a browser with HTML chrome.
It could be a method of a BrowserWindow or a webview (like the more special
purpose getManifest() method in the current Browser API [5]), or it could
be something completely separate.

Ben

1.
http://tola.me.uk/blog/2014/08/07/building-the-firefox-browser-for-firefox-os/
2.
https://developer.mozilla.org/en-US/docs/Web/Events/mozbrowsermanifestchange
3.
https://developer.mozilla.org/en-US/docs/Web/Events/mozbrowseractivitydone
4.
https://github.com/browserhtml/browserhtml/issues/639#issuecomment-138670852
5. https://developer.mozilla.org/en-US/docs/Web/API/Using_the_Browser_API
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML-based chrome and

[Paul Rouget]

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

> We could also potentially emulate other parts of Electron's APIs too, see
> their quick start tutorial
>  to get an idea
> of how their embedding works.

These are 2 different things.

This is about BrowserWindow, which is a different beast.

BrowserWindow is a window that loads a HTML page. That HTML page can
use .
Electron is basically a way to start and handle privileged HTML
windows. It does what shell.js does (but headless!).

For Servo, what i'd like us to do is:
- have a JS runtime à-la nodejs, in Rust (with rust modules)
- one of the rust module will be BrowserWindow, that will spawn a
servo window that would allow the use of webviews
- implement webview/mozbrowser within Servo

I describe that here: https://github.com/servo/servo/issues/7379 and
it's basically a subset of Electron, but with Spidermonkey, Servo, and
Rust.

If you want the same thing with Gecko, you'd need to be able to spawn
gecko windows from a xpcshell-like tool (with an event loop that is
not tied to a window). A headless JS script should be the entry point,
not a window (shell.html).

I'm almost certain that the Electron approach is what should be done
if one wants to build desktop applications with web technologies. And
if such application is a browser, the web engine needs to support
webviews.

An interesting issue we have today is system XHR. We are not sure we
want to pollute the existing XHR code in Servo to add special
behaviors. But in the headless JS, because it's a node-like
environment (no need to think about security or web specifications,
it's part of the app, like shell.html), we could imagine using any
crates.io's packages exposed in the JS world, and implement
cross-origin http requests. We don't want to mix both worlds. The
browser itself (the top level window, above the webviews) can
communicate with the headless JS via message passing.

Basically,  is the Browser API, Electron is nodejs +
BrowserWindow that spawn webkit windows.

--

So what do you want to do here?
You'd like to redesign the Browser API?
Or propose a way to create apps with Gecko with a Electron-like project?
Both?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML-based chrome and

[Benjamin Francis]

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
is also based around mozApps. I'm looking for a viable post-mozApps
solution that could be used by multiple projects.

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'm having to
consider the same route for another project as well.

Ben

On 25 February 2016 at 14:09, Vivien Nicolas  wrote:

> 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 small subset of patches that I need to upload to the repo...).
> It does not implies a new permission model, nor new APIs. Though it rely on
> mozbrowser iframes.
>
> Planula aims to be a very small shell around iframe mozbrowser. No
> features are really built-in, except tabs and an urlbar. The plan is to
> implement *all* features as WebExtensions. In this context a feature means:
> a download manager, a bookmark button + a bookmark manager, Firefox Hello,
> etc..
>
> Basically I would like Planula to be a kind of dedicated sandbox to
> migrate Firefox bits out of XUL/XPCOM in an incremental manner. For
> example, this kind of sandbox can let us implement a particular feature
> (e.g the bookmark button) with pure web technologies, and then try to
> backport it to Firefox itself as a self-contained WebExtension.
>
> This is why Planula re-use as much as possible from Firefox, such as
> about: pages, devtools, etc...
>
> If Planula is ever maintained or used for what it is designed for, one of
> the last thing to do would be to convert  to  mozbrowser>. This will require a bit of plumbing (parts of it beeing
> already done in bug 1238160 as jryan mentioned).
>
> Vivien.
>
> On Wed, Feb 24, 2016 at 9:19 PM, Benjamin Francis 
> wrote:
>
>> Hi,
>>
>> I've been thinking about working towards deprecating "Open Web Apps" (aka
>> mozApps
>> <
>> https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/API/Navigator/mozApps
>> >)
>> in Gecko.
>>
>> For the most part I think mozApps should eventually be replaced by
>> standards-based web apps using Web Manifest, Service Workers etc. I'd love
>> to see a standalone display mode for Firefox which supports these web apps
>> on desktop and mobile to replace the now defunct web runtime, but that's
>> not what this email is about.
>>
>> For the most privileged pieces of UI like the browser chrome of the
>> browser.html project and the Firefox OS system app I think we may need
>> another solution. I'd like us to be able to split Gaia
>>  into chrome (the system pieces) and
>> standard web content (everything else). (I'd also like to see a lot of the
>> current mozApps-only DOM APIs become web services).
>>
>>- In the past we had XULRunner but this has recently been removed and
>> it
>>seems the continued use of XUL is being discouraged in favour of HTML.
>>- There was an attempt at rebooting the Chromeless project
>> but it looks like that was
>>still based on XULRunner.
>>- The browser.html 
>> project
>>currently uses Graphene
>><
>> https://github.com/browserhtml/browserhtml/wiki/Building-Graphene-%28Gecko-flavor%29
>> >,
>>a build of Gecko/Servo which runs locally hosted web content as browser
>>chrome, but that's based 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  (which they
>> already proposed 
>> before ). This would involve
>> a
>> new type of HTML-based chrome including a new  element.
>>
>> Kan-Ru previously did a comparison
>>  of Mozilla's
>> mozBrowser API, Google's  and Microsoft's  and I started
>> to spec something out  with a
>> view
>> to potentially standardising this, but the web lacks the security model
>> needed to expose this API and there's currently not much interest in a
>> standard. So my proposal is a chrome-only  element for Gecko
>> which
>> would replace the mozApps-only mozBrowser API
>> 

Re: HTML-based chrome and

[Vivien Nicolas]

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 small subset of patches that I need to upload to the repo...).
It does not implies a new permission model, nor new APIs. Though it rely on
mozbrowser iframes.

Planula aims to be a very small shell around iframe mozbrowser. No features
are really built-in, except tabs and an urlbar. The plan is to implement
*all* features as WebExtensions. In this context a feature means: a
download manager, a bookmark button + a bookmark manager, Firefox Hello,
etc..

Basically I would like Planula to be a kind of dedicated sandbox to migrate
Firefox bits out of XUL/XPCOM in an incremental manner. For example, this
kind of sandbox can let us implement a particular feature (e.g the bookmark
button) with pure web technologies, and then try to backport it to Firefox
itself as a self-contained WebExtension.

This is why Planula re-use as much as possible from Firefox, such as about:
pages, devtools, etc...

If Planula is ever maintained or used for what it is designed for, one of
the last thing to do would be to convert  to . This will require a bit of plumbing (parts of it beeing
already done in bug 1238160 as jryan mentioned).

Vivien.

On Wed, Feb 24, 2016 at 9:19 PM, Benjamin Francis 
wrote:

> Hi,
>
> I've been thinking about working towards deprecating "Open Web Apps" (aka
> mozApps
> <
> https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/API/Navigator/mozApps
> >)
> in Gecko.
>
> For the most part I think mozApps should eventually be replaced by
> standards-based web apps using Web Manifest, Service Workers etc. I'd love
> to see a standalone display mode for Firefox which supports these web apps
> on desktop and mobile to replace the now defunct web runtime, but that's
> not what this email is about.
>
> For the most privileged pieces of UI like the browser chrome of the
> browser.html project and the Firefox OS system app I think we may need
> another solution. I'd like us to be able to split Gaia
>  into chrome (the system pieces) and
> standard web content (everything else). (I'd also like to see a lot of the
> current mozApps-only DOM APIs become web services).
>
>- In the past we had XULRunner but this has recently been removed and it
>seems the continued use of XUL is being discouraged in favour of HTML.
>- There was an attempt at rebooting the Chromeless project
> but it looks like that was
>still based on XULRunner.
>- The browser.html 
> project
>currently uses Graphene
><
> https://github.com/browserhtml/browserhtml/wiki/Building-Graphene-%28Gecko-flavor%29
> >,
>a build of Gecko/Servo which runs locally hosted web content as browser
>chrome, but that's based 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  (which they
> already proposed 
> before ). This would involve a
> new type of HTML-based chrome including a new  element.
>
> Kan-Ru previously did a comparison
>  of Mozilla's
> mozBrowser API, Google's  and Microsoft's  and I started
> to spec something out  with a view
> to potentially standardising this, but the web lacks the security model
> needed to expose this API and there's currently not much interest in a
> standard. 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
> , to allow you to
> safely embed web content in an application with HTML-based chrome.
>
> We could also potentially emulate other parts of Electron's APIs too, see
> their quick start tutorial
>  to get an
> idea
> of how their embedding works.
>
> Initially this would be used by the browser.html and Firefox OS projects,
> but I think it could be a possible route away from XUL for Firefox in the
> future too.
>
> I've chatted with a few people working on browser.html and Firefox OS about
> this, but I'd like to get broader feedback. Vivien told me he's already
> prototyping a similar solution  to
> the same problem so I'd like to kick off some discussion here about which
> direction we should take.
>
> Thanks
>
> Ben
> __

Re: HTML-based chrome and

[Benjamin Francis]

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 element with
a new name and a cleaner API (the current mozBrowser extension to iframes
is a bit of a mess).

Also, is this restricted to desktop or could it be exposed on other
platforms too (i.e. Android/Gonk)?


To be more explicit about the type of setup I'm proposing...

Some kind of configuration/manifest which specifies a main worker script,
the example below is like Node's package.json (for Firefox OS which
provides its own window manager this could probably just point directly at
an HTML file, but for browser.html they want to be able to instantiate
multiple windows in the native window manager from a worker script):

{
  "name": "my-browser",
  "version": "1.0",
  "main": "main.js"
}

A script which instantiates a browser window with HTML chrome:

app.on('ready') {
  mainWindow = new BrowserWindow({ width: 800, height: 600});
  mainWindow.loadURL('file://.../index.html');
}

HTML browser chrome which embeds a webview:



  

My Browser

  
  

http://google.com";>
  



Browser logic which uses the webview API:

var backButton = document.getElementById('back-button');
var tab1 = document.getElementById('tab1');
backButton.addEventListener('click', function() {
  var tab1.goBack();
}

The chrome code could then access OS-level services via either further
chrome-only JavaScript APIs (with Electron these are Node APIs separate
from Webkit) or local web services providing some kind of RESTful API.

This is heavily based on Electron's API as a starting point and I'm
completely open to suggestions for something more Gecko-like. For example,
the configuration in package.json could be done in mozconfig or prefs
instead if that's more appropriate.

Ben

On 24 February 2016 at 20:38, J. Ryan Stinnett  wrote:

> We'll soon have access to  in desktop Firefox (see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1238160).
>
> I realize you are proposing a different API than mozbrowser, but I
> just wanted to point out that there will be some HTML-based approach
> for browser chrome available on desktop soon.
>
> - Ryan
>
> On Wed, Feb 24, 2016 at 2:19 PM, Benjamin Francis 
> wrote:
> > Hi,
> >
> > I've been thinking about working towards deprecating "Open Web Apps" (aka
> > mozApps
> > <
> https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/API/Navigator/mozApps
> >)
> > in Gecko.
> >
> > For the most part I think mozApps should eventually be replaced by
> > standards-based web apps using Web Manifest, Service Workers etc. I'd
> love
> > to see a standalone display mode for Firefox which supports these web
> apps
> > on desktop and mobile to replace the now defunct web runtime, but that's
> > not what this email is about.
> >
> > For the most privileged pieces of UI like the browser chrome of the
> > browser.html project and the Firefox OS system app I think we may need
> > another solution. I'd like us to be able to split Gaia
> >  into chrome (the system pieces)
> and
> > standard web content (everything else). (I'd also like to see a lot of
> the
> > current mozApps-only DOM APIs become web services).
> >
> >- In the past we had XULRunner but this has recently been removed and
> it
> >seems the continued use of XUL is being discouraged in favour of HTML.
> >- There was an attempt at rebooting the Chromeless project
> > but it looks like that
> was
> >still based on XULRunner.
> >- The browser.html 
> project
> >currently uses Graphene
> ><
> https://github.com/browserhtml/browserhtml/wiki/Building-Graphene-%28Gecko-flavor%29
> >,
> >a build of Gecko/Servo which runs locally hosted web content as
> browser
> >chrome, but that's based 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  (which they
> > already proposed 
> > before ). This would
> involve a
> > new type of HTML-based chrome including a new  element.
> >
> > Kan-Ru previously did a comparison
> >  of Mozilla's
> > mozBrowser API, Google's  and Microsoft's  and I
> started
> > to spec something out  with a
> view
> > to potentially standardising this, but the web lacks the security model
> > needed to expose this API and there's currently not much interest in a
> > standard. So my proposal is a chrome-only  element for Gecko
> which
> > woul

Re: HTML-based chrome and

[J. Ryan Stinnett]

We'll soon have access to  in desktop Firefox (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1238160).

I realize you are proposing a different API than mozbrowser, but I
just wanted to point out that there will be some HTML-based approach
for browser chrome available on desktop soon.

- Ryan

On Wed, Feb 24, 2016 at 2:19 PM, Benjamin Francis  wrote:
> Hi,
>
> I've been thinking about working towards deprecating "Open Web Apps" (aka
> mozApps
> )
> in Gecko.
>
> For the most part I think mozApps should eventually be replaced by
> standards-based web apps using Web Manifest, Service Workers etc. I'd love
> to see a standalone display mode for Firefox which supports these web apps
> on desktop and mobile to replace the now defunct web runtime, but that's
> not what this email is about.
>
> For the most privileged pieces of UI like the browser chrome of the
> browser.html project and the Firefox OS system app I think we may need
> another solution. I'd like us to be able to split Gaia
>  into chrome (the system pieces) and
> standard web content (everything else). (I'd also like to see a lot of the
> current mozApps-only DOM APIs become web services).
>
>- In the past we had XULRunner but this has recently been removed and it
>seems the continued use of XUL is being discouraged in favour of HTML.
>- There was an attempt at rebooting the Chromeless project
> but it looks like that was
>still based on XULRunner.
>- The browser.html  project
>currently uses Graphene
>
> ,
>a build of Gecko/Servo which runs locally hosted web content as browser
>chrome, but that's based 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  (which they
> already proposed 
> before ). This would involve a
> new type of HTML-based chrome including a new  element.
>
> Kan-Ru previously did a comparison
>  of Mozilla's
> mozBrowser API, Google's  and Microsoft's  and I started
> to spec something out  with a view
> to potentially standardising this, but the web lacks the security model
> needed to expose this API and there's currently not much interest in a
> standard. 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
> , to allow you to
> safely embed web content in an application with HTML-based chrome.
>
> We could also potentially emulate other parts of Electron's APIs too, see
> their quick start tutorial
>  to get an idea
> of how their embedding works.
>
> Initially this would be used by the browser.html and Firefox OS projects,
> but I think it could be a possible route away from XUL for Firefox in the
> future too.
>
> I've chatted with a few people working on browser.html and Firefox OS about
> this, but I'd like to get broader feedback. Vivien told me he's already
> prototyping a similar solution  to
> the same problem so I'd like to kick off some discussion here about which
> direction we should take.
>
> Thanks
>
> Ben
> ___
> 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

HTML-based chrome and

[Benjamin Francis]

Hi,

I've been thinking about working towards deprecating "Open Web Apps" (aka
mozApps
)
in Gecko.

For the most part I think mozApps should eventually be replaced by
standards-based web apps using Web Manifest, Service Workers etc. I'd love
to see a standalone display mode for Firefox which supports these web apps
on desktop and mobile to replace the now defunct web runtime, but that's
not what this email is about.

For the most privileged pieces of UI like the browser chrome of the
browser.html project and the Firefox OS system app I think we may need
another solution. I'd like us to be able to split Gaia
 into chrome (the system pieces) and
standard web content (everything else). (I'd also like to see a lot of the
current mozApps-only DOM APIs become web services).

   - In the past we had XULRunner but this has recently been removed and it
   seems the continued use of XUL is being discouraged in favour of HTML.
   - There was an attempt at rebooting the Chromeless project
    but it looks like that was
   still based on XULRunner.
   - The browser.html  project
   currently uses Graphene
   
,
   a build of Gecko/Servo which runs locally hosted web content as browser
   chrome, but that's based 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  (which they
already proposed 
before ). This would involve a
new type of HTML-based chrome including a new  element.

Kan-Ru previously did a comparison
 of Mozilla's
mozBrowser API, Google's  and Microsoft's  and I started
to spec something out  with a view
to potentially standardising this, but the web lacks the security model
needed to expose this API and there's currently not much interest in a
standard. 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
, to allow you to
safely embed web content in an application with HTML-based chrome.

We could also potentially emulate other parts of Electron's APIs too, see
their quick start tutorial
 to get an idea
of how their embedding works.

Initially this would be used by the browser.html and Firefox OS projects,
but I think it could be a possible route away from XUL for Firefox in the
future too.

I've chatted with a few people working on browser.html and Firefox OS about
this, but I'd like to get broader feedback. Vivien told me he's already
prototyping a similar solution  to
the same problem so I'd like to kick off some discussion here about which
direction we should take.

Thanks

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