lukasza@ in what situation the main frame is remote? Does that mean that webview does not have any local frame? That seems a little weird.

One example is if the main frame comes from foo.com and has a subframe from bar.com, then (since these frames are cross-origin and cannot ever synchronously script each other) the main frame and the subframe can be put into 2 different renderer processes (this will happen when running with --site-per-process cmdline flag and/or with --isolate-origins flag asking to isolate either foo.com or bar.com).  In this situation:

- foo.com renderer would contain
    - LocalFrame for the main frame (from foo.com)
    - RemoteFrame for the subframe (from bar.com).
      The remote frame would proxy information to/from the other renderer
      (where the corresponding LocalFrame is hosted).

- bar.com renderer would contain
    - LocalFrame for the subframe (from bar.com)
    - RemoteFrame for the main frame (from foo.com)
      The remote frame would proxy information to/from the other renderer
      (where the corresponding LocalFrame is hosted).

Does that help?

+ekaramad@, as I think this issue might be related to  issue 784982 .

I'm guessing that WebFrameWidgetImpl/Base don't have an AnimateDoubleTapZoom implementation, but this *may* actually be correct, since OOPIFs shouldn't zoom independently of the mainframe anyways.

The correct solution may be to make sure that the bouble-tap event, kGestureDoubleTap, is always sent to the main frame, regardless of whether it occurs over an OOPIF or not. Of course, this may depend somewhat on whether this event is intended to be cancelable by JS handlers or not. And, if we're just sending the double-tap itself to the mainframe, we may need to send a complete Gesture sequence (and maybe prevent the original GestureTapDown on the OOPIF, or at least cancel it, not sure).

Since I'm in the neighbourhood investigating OOPIF and PSF factor stuff, I'll see if I can take a stab at this ...

According to bokan@ double-tap zoom will coming to CrOS shortly (if it's not already there), so giving this issue a target milestone.

+Ahmed FYI

Double tap to zoom is already available on Chrome OS in tablet mode since M-69.

Not for out-of-process iframes (site isolation) it isn't :-)

Updating affected platforms
Mac uses this for a double-tap with two fingers on a touchpad
Chrome OS as per c#10

James, any status updates for this?  How much work will be involved here?  We might want to fix this for launching some form of site isolation on Android.

I confirmed this is broken with the following repro:

1. Enable strict site isolation via chrome://flags/#enable-site-per-process

2. Go to http://csreis.github.io/tests/cross-site-iframe.html

3. Click one of the two "Go cross-site" buttons.

4. Double-tap inside the iframe.

The iframe should zoom in, and this is what happens with site isolation disabled, but nothing happens when site isolation is enabled.  I confirmed on Android canary 71.0.3563.0 on a Nexus 4 as well as on Pixel C in portrait mode (in landscape mode things are apparently wide enough to not need a zoom on that page).

I'm going to work on this in the coming week. It shouldn't be too hard ... a few IPCs and some plumbing.

The work on this bug is complete, but I'm going to dupe it back into the original bug as that's what I linked on the relevant CLs.

Adding label to track this for shipping site isolation on Android.

James, I've tried this on canary 73.0.3664.2 on a Nexus 5, using steps in #c13. Double-tap on the iframe does zoom now, which is great.  One small thing I've noticed is that it zooms a bit closer to the text, when compared to the non-OOPIF case (when starting from httpS://csreis.github.io/tests/cross-site-iframe.html in step 2).  In non-OOPIF, it zooms to the iframe's width (so all three buttons on the page are visible), and the next double-tap zooms out to the whole page.  With the OOPIF, it zooms to about 2/3 of the iframe (cutting off the third button, and some of the second button), and another double tap sometimes zoom out to just the frame width, and then a third double-tap then zooms out to the whole page.  Not sure if you are already aware of this, or if this is important to fix, but mentioning just in case.  (Also not sure if this should be part of issue 734209.)