990972 - Support subframe zooming with APZC

Status: NEW

(Core :: Panning and Zooming, enhancement, P3)

Description

[Kartikaya Gupta (email:[e-mail])]

For desktop Firefox (e.g. on OS X) we have the chrome section and content section living in the same process (assuming no e10s). If we want to be able to zoom the content with APZC then we need to support subframe zooming, which we do not currently support. I'm not yet sure we need this but filing a bug to track the discussion.

Comment 1

[Timothy Nikkel (:tnikkel)]

Didn't metro do this already?

Comment 2

[Kartikaya Gupta (email:[e-mail])]

I was discussing this with Botond, and we came to the conclusion that it only worked on Metro "by accident". It worked because the root scrollable frame on metro was the content frame, and so when we zoomed it didn't zoom the URL bar. I think that on OS X and probably other desktop platforms the root scrollable frame will be higher up in the tree and include bits of the chrome.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #0)
> If we want to be able
> to zoom the content with APZC then we need to support subframe zooming,
> which we do not currently support.

So after discussion with tn and botond, this statement is wrong. There are other ways to zoom the content without implementing full subframe zooming. Removing the dependency, but I'll leave this to track subframe zooming which we'll probably want long-term anyway.

Comment 4

[Botond Ballo [:botond]]

One of the issues we'll need to address if we implement subframe zooming is the handling of overflow:hidden zoomed subframes.

Currently, if the RCD-RSF is overflow:hidden, we allow zooming it in and scrolling around within the original bounds, but we never change the Gecko scroll position in this process (because Gecko doesn't expect user input to change the scroll position of an overflow:hidden scroll frame). Instead, we track the visual scroll position in APZ, and keep track of the delta between the two. When sending an input event (whose original coordinates are relative to the visual scroll position) to Gecko, we apply that delta to its coordinates to yield coordinates relative to the Gecko scroll position.

The point at which this delta is applied, regardless of the scroll frame to which the delta pertains, is before entering Gecko hit testing. This is fine for scenarios where the scroll frame in question is the RSF of the document in which we start the Gecko hit testing. If it's not, however, then having applied the delta to it _before_ hit testing against enclosing frames, can cause the hit test against the enclosing frames to fail.

As only the RCD-RSF is currently zoomable, this hasn't been a problem, except on Fennec, where the RCD is not the root document of the process, and thus not where the hit testing process starts (see bug 1229752 comment 16); there, a targeted fix was applied (re-targeting the event from the root document to the RCD, so the problematic hit tests are skipped).

If we support subframe zooming, however, and want to have the same behaviour for zoomed overflow:hidden subframes, we'll run into this problem and need a proper fix for it. I believe a proper fix would be along the lines of changing the place the delta is applied, from all the deltas being applied at the beginning of the Gecko hit testing, to each delta being applied as the hit test enters the scroll frame to which the delta pertains.

Comment 5

[Andrey Bienkowski]

https://bugzilla.mozilla.org/show_bug.cgi?id=1548706