On 25 February 2016 at 16:22, Paul Rouget <p...@mozilla.com> wrote: > As a user, using <iframe mozbrowser="true"> or <webview> 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 <webview>. > 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, <webview> 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
