On 16 June 2015 at 16:24, Paul Rouget <[email protected]> wrote: > In bug 1174733, I'm proposing a patch to implement the equivalent of > Google's webview.executeScript: > > https://developer.chrome.com/apps/tags/webview#method-executeScript > > This will be useful to any consumer of the Browser API to access and > manipulate the content. >
In 2011 when we started talking about how to build a web browser using web technologies for B2G we discussed two options: 1. Provide the ability to inject scripts into cross-origin iframes with access to the whole document 2. Build an explicit DOM API which just pokes the holes needed in the cross-origin boundary to access the information needed to build a browser, and nothing more What you're talking about is the first option. We chose the second option because we wanted to build a relatively safe API which could be used to build third party browser apps (and other webview type use cases). I've written about this in some length in this blog post https://hacks.mozilla.org/2014/08/building-the-firefox-browser-for-firefox-os/ The Browser API we have today is accessible to privileged apps, there are currently 13 apps in the Firefox Marketplace using the Browser API. Those apps can do basic things like frame a cross-origin web page with X-Frame-Options headers, navigate it and know when its location, title, icon etc. change, but they can't read or modify the content of all the web pages you visit and read your credit card details etc. The most privileged thing the Browser API provides is getScreenshot(), which I have argued should be a separate API only available to certified apps for this very reason. The existing <iframe mozbrowser> element is very similar to Google's <webview> element in Chrome OS and Microsoft's <x-ms-webview> element in Windows. I still hold out hope that one day we might be able to standardise this as a new <webview> HTML element http://benfrancis.github.io/webview/ - what's missing is a standards-based security model fit for the purpose of exposing this API to web content (as is the issue with many of our other APIs). It seems taking the script injection approach is a fundamentally different approach to the current Browser API and would essentially give the embedding document chrome privileges over the embedded document and remove the cross-origin boundary entirely. This is a valid approach, but would essentially make the Browser API redundant and there would be no point in ever trying to standardise it. I'm not saying that you shouldn't take this approach, it would certainly make some of the new use cases we have around Linked Data easier because we could just walk the DOM of any web page the user visits. But I want to make it clear that this is not just an addition to the Browser API, it's a replacement for it. My preference would be to keep the current approach and extend it where needed for browser.html rather than taking this shortcut, but I am probably biased. I know Jonas thinks there's little prospect of standardising this API any time soon. Please keep me in the loop in this discussion because it has huge implications for the work me and my team do. In particular, let's talk about what data browser.html needs access to to build its "tab previews" because it sounds very similar to our use cases of extracted Linked Data from a page. Thanks Ben _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
