+kenrb,+wjmaclean

So OOPIFs have a problem in that they fire 2 resize events when we do Ctrl+/- zooming, try: http://output.jsbin.com/sodajor which prints the number of resize events received. Here's the sequence of events:

1) Ctrl+ received in main frame
2) Main frame propagates the zoom factor to the child via WebViewImpl::PropagateZoomFactorToLocalFrameRoots
3) Remote child gets a new zoom factor which changes it's viewport size so it'll dispatch a resize event
4) Main frame does layout with the new zoom factor and resizes the iframe container
5) Browser realizes the OOPIF's container in the main frame has changed size. We then sync the new size to the RenderWidget via RenderWidget::SynchronizeVisualProperties
6) This again changes the viewport size so we dispatch another resize event.

Technically, we shouldn't dispatch a resize at all since the window.innerWidth|Height inside the iframe hasn't changed. If we zoom by 2X, the iframe is physically twice as large but the CSS pixels are also twice as large so the size in CSS pixels hasn't changed. There's three possible solutions as I see it:

1) Move page zoom factor propagation to happen in SynchronizeVisualProperties.
2) Add state inside Blink where we decide to dispatach the event to prevent dispatching in the zoom case until we've synchronized visual properties
3) Accept the broken behavior

1 feels like the "intuitive" solution but I don't like that it's plumbing an internal blink concept like zoom into places it doesn't really belong.

2 seems like it'll be complicated and may introduce more edge cases

3 seems sad but, comparing browsers, only Edge handles this correctly. Chrome, Safari, Firefox all fire 1 or 2 resizes at the iframe so I'm not sure anyone relies on this today. An additional issue here is bug 826457 which happens during load - this may cause actual breakage.

Thoughts? (patch for context: https://chromium-review.googlesource.com/c/chromium/src/+/1089110)

+eae@ for layout-side perspective. Note: this affects not just ctrl+/- zooming but also loading because --use-zoom-for-dsf means we set a page zoom factor during load on a renderer.

I agree that option one seems like the most "correct" but share you concern about the leaky abstraction.

Option 2 would effectively deferring resize events until all OOPIF's in the document have been updated, right?

It would defer the resize event in the OOPIF until it's had a visual sync (not necessarily all OOPIFs) which may or may not change the iframe widget's size. We would decide at that point whether the viewport size in CSS pixels has changed and we need to dispatch.

OTOH, it relies on timing across processes so would likely fail in many situations. E.g.

A) Send SetPageZoomFactor IPC to child
B) Layout in parent frame and submit new surface sizes to browser
C) Browser syncs visual state with child

Presumably we might sync visual state between A and B so it can still fail...

Removing blocking 737777 as we disable the test on Android.

Note that we've implemented solution 1:

https://cs.chromium.org/chromium/src/content/common/visual_properties.h?q=VisualProperties&sq=package:chromium&g=0&l=80

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3d98424ea60f6ca5504d5130af678b0da66b9fa7

commit 3d98424ea60f6ca5504d5130af678b0da66b9fa7
Author: Ella Ge <eirage@chromium.org>
Date: Mon Jan 21 15:54:29 2019

Prevent sending resize event before load complete

SitePerProcessBrowserTest::NoResizeAfterIframeLoad was disabled on
Android when we enabled zoom-factor-for-dsf.
It was failing because when there was zoom factor, there was an extra
layout when setting the page_zoom_factor for the first time.

This CL supressed the UpdateStyleAndLayout on Update zoom factor
if it's the first layout and we don't have the LayoutSize yet.

Bug:  851049 
Change-Id: If2b3fc05624c659d5fb83e50a9edf34ab0231e5c
Reviewed-on: https://chromium-review.googlesource.com/c/1409733
Commit-Queue: Ella Ge <eirage@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#624590}
[modify] https://crrev.com/3d98424ea60f6ca5504d5130af678b0da66b9fa7/content/browser/site_per_process_browsertest.cc
[modify] https://crrev.com/3d98424ea60f6ca5504d5130af678b0da66b9fa7/third_party/blink/renderer/core/frame/local_frame.cc