On Wed, Jun 17, 2015 at 2:06 PM, Benjamin Francis <bfran...@mozilla.com> wrote: > On 16 June 2015 at 16:24, Paul Rouget <p...@mozilla.com> 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.
I'm introducing a new permission for executeScript. > 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. Well, that the thing. "what data browser.html needs access to to build its tab previews" is not a thing we want to set in stone. We want to be able to change that as often as we want without tweaking platform's code all the time. Extending the API every time we want to do something that goes beyond the API capabilities is painful and slow. The executeScript approach makes our life a lot easier and gives us a lot more flexibility. -- Paul _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
