On Wed, Feb 24, 2016 at 9:19 PM, Benjamin Francis <bfran...@mozilla.com> wrote: > 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.
As a user, using <iframe mozbrowser="true"> or <webview> 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 > <http://electron.atom.io/docs/v0.36.8/tutorial/quick-start/> 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 <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, 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? _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
