1641279 - Reflect the resolution better in the frame tree model

Status: NEW

(Core :: Layout, task, P3)

Description

[Botond Ballo [:botond]]

Pinch-zooming causes the page content to be drawn with a resolution scale applied. The resolution applies to most frames in the frame tree, but not the viewport's scrollbar frames.

Prior to bug 1556556, applying the resolution was mostly a compositor-only effect. Applying it to the page content but not the viewport scrollbars was accomplished by drawing the page content and the viewport scrollbars into different layers, and having the compositor apply the resolution scale to the page content layers but not the scrollbar layers. The frame tree was largely oblivious to the existence of the resolution. This meant that e.g. main-thread hit testing could not correctly target scrollbars when zoomed in or out, but that was fine because we did not need to be able to target scrollbars on mobile (they cannot be dragged on mobile).

Now that we're bringing pinch zooming to desktop, we need to be able to target scrollbars when zoomed in or out, and so in bug 1556556 we made some changes to make the frame tree more aware of the resolution. As part of those changes, we think of there being a "zoom boundary" that includes the page content but excludes the scrollbars. In terms of the frame tree, we think of the root content document's ViewportFrame and HTMLScrollFrame frame as being outside the zoom boundary, along with the HTMLScrollFrame's scrollbar frames, but the HTMLScrollFrame's scrolled frame (typically a CanvasFrame) as being inside. The resolution is applied or unapplied when crossing this boundary.

However, in bug 1637135, we discovered that this conceptual model conflicts with mobile viewport sizing, which is a feature of mobile browsing where a page can override the initial containing block size (ICB size) into which the page contents are reflowed, to be something different than the physical size of the content viewer. (This is accomplished via a <meta name="viewport"> tag, using the width and (less commonly) height descriptors.)

The ICB size is an "inside the zoom boundary" quantity, since pinch-zooming changes the scale at which the page contents are displayed without reflowing.

The conflict arises from the fact that we currently size the ViewportFrame and HTMLScrollFrame to the ICB size, which clashes with trying to think of these frames as being outside the zoom boundary.

The intent of this bug is to reconcile this conflict by changing the frame tree model to represent the resolution in a better way. I'm not sure yet what exactly that would look like.

At a high level, I think there needs to be a frame whose size is the physical content viewer size and which is clearly outside the resolution, and a frame whose size is the ICB size and which is clearly inside the resolution. The scrollbar frames need to be descendants of the former and not the latter. (In bug 1637135 comment 20, I wrote that the latter should be the CanvasFrame, but I now realize that's wrong since the CanvasFrame's size needs to be the size of the entire scrolled content. Possibly we need a new frame type.)