<iframe mozbrowser> implementation plan for WebExtensions

the-plan.md

Implementing iframe mozbrowser> bug 1318532

Opportunities with this API

• Tile Tabs
• Create a wrapper around web content (à la Responsive design Mode)
• Make use of container tabs properties for iframes
• More secure alternative to overriding CSP to make web content iframe-able

Existing Attributes

• All iframe supported attributes
• noisolation (sets whether the docshell should be isolated from the tab I think, not sure)
• remote (makes the iframe content run in a different process, but that implies no direct contentWindow access)

-> Issue: I don't think WebExtensions should be able to set these, but we should rather choose some sensible default. Chrome allows access to the contentWindow, but also has getProcessId which implies remoteness ?

Existing mozbrowser APIs

From https://dxr.mozilla.org/mozilla-central/source/dom/webidl/BrowserElement.webidl

I plan on progressively enable these APIs and test them at the same time. All of them should work on Firefox desktop, but since they were initially built for Firefox OS, it's better to do testing. Especially since the only usage of iframe mozbrowser on desktop (Responsive design mode) doesn't make use of any of these APIs.

P1 APIs (should be initially available):

• goBack()
• goForward()
• getCanGoBack()
• getCanGoForward()
• reload()
• stop()

P2 APIs (potentially as follow ups)

• zoom()
• getScreenshot()
• purgeHistory()
• mute()
• unmute()
• getMuted()
• setVolume()
• getVolume()
• getContentDimensions()
• executeScript()

P3 (may need modifications)

• findAll()
• findNext()
• clearMatch()
• download()

P4 (need decisions):

• setVisible()
• getVisible()
• setActive()
• getActive()
• addNextPaintListener
• removeNextPaintListener
• sendMouseEvent()/sendTouchEvent()
• getWebManifest()

Chrome apps <webview> APIs

https://developer.chrome.com/apps/tags/webview#toc

I intent to implement these APIs:

• getUserAgent/setUserAgent/isUserAgentOverriden

Nice to have:

• insertCSS()
• print()
• All webview events
• contentWindow
• request
• contextMenus

Is partition useful ?

-> Issue: should we rename the mozbrowser APIs to match Chrome webview APIs ?

Extra APIs

• Container tabs
  • getCookieStoreId
  • setCookieStoreId
  • isCookieStoreIdOverriden
• Ideas ??

Other issues

• Should the add-on request a special permission ?
• Do we want to try and match chrome as closely as we can ?
  • Maybe make webview> an alias to iframe mozbrowser>

Hello, how has it been going building this on Firefox Desktop? mozbrowser can be the perfect solution to my problem right now. :)