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:
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>My Browser</title>
<script type="text/javascript" src="index.js"></script>
</head>
<body>
<button id="back-button">
<webview id="tab1" src="http://google.com";></webview>
</body>
</html>
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 <jry...@gmail.com> wrote:
> We'll soon have access to <iframe mozbrowser> 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 <bfran...@mozilla.com>
> 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
> > <https://github.com/mozilla-b2g/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
> > <https://github.com/mikedeboer/chromeless2> but it looks like that
> was
> > still based on XULRunner.
> > - The browser.html <https://github.com/browserhtml/browserhtml/>
> 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 <http://electron.atom.io/> (which they
> > already proposed <https://github.com/browserhtml/browserhtml/issues/639>
> > before <https://github.com/servo/servo/issues/7379>). This would
> involve a
> > new type of HTML-based chrome including a new <webview> element.
> >
> > Kan-Ru previously did a comparison
> > <https://wiki.mozilla.org/WebAPI/BrowserAPI/Common_Subset> of Mozilla's
> > mozBrowser API, Google's <webview> and Microsoft's <webview> and I
> started
> > to spec something out <https://github.com/benfrancis/webview/> 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 <webview> element for Gecko
> which
> > would replace the mozApps-only mozBrowser API
> > <https://developer.mozilla.org/en-US/docs/Web/API/Using_the_Browser_API
> >,
> > along the lines of Electron's <webview> element
> > <http://electron.atom.io/docs/v0.36.8/api/web-view-tag/>, 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
> > <http://electron.atom.io/docs/v0.36.8/tutorial/quick-start/> 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 <https://github.com/vingtetun/planula> 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
