WebAPI/EmbeddedBrowserAPI

A proposed API to allow a web application extra privileges over certain iframes in order to allow that application to manage the user's interaction with other web sites and web applications.

This is being tracked as bug 693515 (alias browser-as-webapp).

Functionality needed

Example applications might be a web-based graphical shell for interacting with web apps (e.g. Gaia's home screen app) or a web browser implemented in HTML (e.g. Gaia's browser app).

• Listen for cross-origin events - allow the outer application to catch events from the content inside the iframe, even if that content is from a different origin
  • Load Start - When the iframe starts loading a new document (needed for tracking browsing history). Also need to know when iframe's children start loading, or do XHR, etc.
  • Progress monitor - to monitor the progress of the document being loaded inside the iframe (needed to implement a progress bar)
  • Load Stop - When the iFrame finishes loading a new document
  • Title Change - When the title of an HTML document inside the iframe changes
  • URL change
  • Favicon URL change
  • Security State - When we load a page over SSL. Lock icon, cert warning page.
• Access to content - provide access to content inside the iframe
  • Get Title - Get the title of the current HTML document inside the iframe
  • Get URL (bug 708176) - Allow app to access URLs (and potentially scroll position) of resources loaded in iframes so a browsing session can be restored at a later date
  • Get favicon URL - As this can be contained inside the HTML document itself
  • Get thumbnail - Get a thumbnail image of the content of the iframe, for use in graphical window manager/tab switching type features
  • Find in page - Search the text of an HTML document inside an iframe
  • Read history data (bug 708179) - You really don't want to re-implement session history in js, or any other language for that matter.
• Control iframe - Allow programmatic control of the iframe
  • Stop Load (bug 709759) - Programatically stop the iframe from loading a document
  • Reload - Programmatically reload the contents of the iframe. (Support different types of reload: normal, charset change, force)
  • Zoom - Programatically make the iframe content larger or smaller
• Suppress some security measures
  • Suppress XFrame-Options Header - Render the contents of a document inside the iframe, even if it was returned with an X-Frame-Options DENY or SAMEORIGIN header. (e.g. web sites like GMail which return this header to prevent phishing scams will still be rendered inside this special iframe).
• Manage some window.* APIs
  • alert(), confirm(), prompt()
  • open()
• Red pill / blue pill -- pages shouldn't be able to tell that they're in an HTML browser.
  • window.top should stop at the topmost browser iframe (bug 704037)

Secondary concerns

• View-source
• Content-policies (Adblock, NoScript)
• Inject JS into page (Greasemonkey)
• outerWidth / outerHeight
• restrict which windows are traversed when searching for a named window
• DOM inspector

Security Model

These permissions may need to be explicitly given by the user for specific web apps.

This could take the form of a permission requested during the "installation" of an Open Web App and listed in the Open Web App manifest. This could be phrased along the lines of "Allow this app to look inside and control other apps and web sites you use."

Implementation

Low-level vs. high level - generalised low level message passing system/access to the DOM or high level methods for individual use cases?

Previous Work

Note previous similar work done on Mozilla Chromeless https://github.com/mozilla/chromeless/blob/master/modules/lib/web-content.js

Some of these features are provided by the XUL browser element, but the proposal here is to provide this functionality through HTML.