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

nsAutoArrayPtr has been removed, please use UniquePtr<T[]> instead

[Nathan Froyd]

As the subject says, via bug 1229985.

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

Thanks,
-Nathan
___
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

[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: APNG and Accept-Encoding

[Gervase Markham]

On 22/02/16 14:58, Xidorn Quan wrote:
> But older Firefoxes go away fairly quickly, so I wouldn't consider
> this as a valid reason blocking us moving forward.

I'm not sure that's as true as we'd like it to be :-|

Gerv

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

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.

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