1102469 - [email] Use platform capabilities to improve HTML email viewing

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[James Burke [:jrburke]]

The motivations for changing how HTML email viewing right now was most recently triggered by bug 1092440, allowing text selection in the email app. One of the main areas of text selection interest would be email bodies. This ticket may end up being a meta tag to improve the experience, and will likely need some platform changes to really finish it out.

The main goal of this change is to remove code that the email app does to programmatically handle zoom and capture all events, to leverage the platform for zooming and main event handling, so that features like text selection can work. First, a discussion of the goals and issues of showing HTML email, then a discussion of possible implementation paths.

## Theory

The email app has these goals for showing HTML email:

1) Must be script-safe for the user. It should not be possible for scripts to run in the HTML email. At least, not scripts from the email contents itself. It is likely desirable for the area that shows the HTML email have some safe script hooks to the email app logic. Right now there is a sanitizer used by email to limit the HTML options, but it is important to also have platform capabilities like Content Security Policy (CSP) to catch things if they were to fall through.

2) Avoid social engineering attacks that get users to tap on links to go to undesirable web sites. This is currently supported in the email app by the email app capturing all click events and showing a popup with the URL shown.

3) Does not broadcast data about the user unless user explicitly takes action. This is one of the reasons showing images in an email is off by default, and the user needs to explicitly tap to load them.

4) Content should be zoomable, with the default of being zoomed out such that the width of the content is fully visible as the default, initial view.

5) The email app needs to know how big the content is to properly adjust containing element heights to give the user the right vertical scrolling behavior.

6) Content should be scrollable. Scrolling would ideally be buttery smooth APZ goodness.

## Current mechanics

Email uses an non-mozbrowser iframe at the moment to show email, and disables pointer-events into the iframe. The email app uses script to communicate with the iframe.contentDocument/contentWindow for the following reasons:

* Tap detection for links.
* Event detection fo load/scale to know how to size the iframe div.
* Manually scaling the content via a `transform: scale()` at a limited set of discrete zoom levels, to avoid memory spikes, see bug 1058900.
* If the user taps "load images", then the iframe's DOM is manipulated to show the images.

## Tensions

The email app would like to just delegate to the platform for scrolling, zooming and allow events to happen first in the iframe, so that things like text selection can work, but the zooming needs to have good performance characteristics, and the app does want to listen for or cancel some user events (like initial link tapping).

The app needs to allow some script communication between the iframe contents and the outer app, but not allow maliciousness from the email body source.

## Possible implementation

Remove pointer-events: none from the iframe, and allow events to happen first in the iframe.

Use iframe.srcdoc to set up the iframe content.

Use Content Security Policy with a policy that allows script nonces to allow the execution of one nonce-blessed inline script to set up a postMessage channel to the outer app. That script would listen for link taps, could receive postMessaged messages to update image contents, and notify out when the body loads/changes, to allow the app to resize the iframe to fit the content.

This means allowing setting the CSP policy in a META tag, since this content is not served from a server. Bug 663570 tracks that feature.

Script nonces for CSP support seeme to be supported in nightly, according to MXR, but might need to confirm if the flags for it are turned on an available for Firefox OS apps (privileged and certified would be fine).

Possibly move to a mozbrowser iframe. That choice depends on what the platform thinks might work well for the goals above. The events available on a mozbrowser are tempting to use though. Navigations can be cancelled, so might be a way to get link taps instead of the nonce-enabled inline script inside the iframe.

There could be other solutions to address the goals, but the lack of a safe script communication bridge to inside the iframe/mozbrowser seemed to be the biggest stumbling block, so some solution for that likely needs to come first.

## Platform enhancements that help

So given the above, fixing these platform bugs would seem to allow us going further:

* Bug 663570: meta tag for CSP policy. This could allow us to then set up a safe postMessage communication channel with the iframe, also assuming script nonce policies are also available.

* Bug 1020199: enabling APZ for child iframes: this would help in considering the removal of the manual zoom code. Hopefully the performance does not have the memory spikes that led to bug 1058900.

Still might need some research into setting up proper initial zoom level. For email, we do not want an initial value of 1, but freqently something less than 1 so that the whole content can fit. Hopefully the "viewport" meta tag can help with that. That meta tag is normally focused on setting up a scaling of 1, where we want to say "whatever the natural width of the content is, zoom out to that".

We could likely make some improvements by just getting the safe scripting bridge set up, so in order of prioritization, a solution to that is most important.

Comment 2

[BMO Automation]

Firefox OS is not being worked on