Using the per-revision bisect providing the bisect results,
Good build:58.0.3025.0 (Revision:453134).
Bad build:58.0.3026.0 (Revision:453454).

You are probably looking for a change made after 453317 (known good), but no later than 453318 (first known bad).

CHANGE-LOG URL:
---------------
https://chromium.googlesource.com/chromium/src/+log/09ac3a21d0b908ca26d0898f58ea77be7e9462d2..9e1897b5c7dab9c190fc3c919a1c4662af63b3e6

From the CL above, assigning the issue to the concern owner

@nasko : Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Review-Url:  https://codereview.chromium.org/2715363002
Note :Able to reproduce the issue in Win 10.0,Ubuntu 14.04 & Mac 10.12.3 and Able to reproduce in latest Canary #59.0.3053.3
Adding Release Block-Stable for this issue.Please remove if not the case.

Adding labels and creis@, kenrb@ for context.

Also, adding thestig@, in case there is some state that Print Preview affects and can contribute to this behavior.

Not PDF since this is not our PDF viewer.

Maybe if some printing code failed to clean up after itself after cancelling the print preview?

The bisect showed that this is linked to --isolate-extensions, which means that it only happens with the extension PDF viewer is within an OOPIF. Input events all seem to be reaching it fine, so it seems likely to be related to printing within OOPIFs.

One interesting thing is the rest of the PDF extension works. It's just the zoom dropdown that stopped working.

The dropdown is just a <select> named scaleSelect. I guess I'll look in the code for that in Blink and see what's happening there.

In HTMLSelectElement::showPopup(), visibleBoundsInVisualViewport().isEmpty() is returning true, so the select element's drop down never pops up. If I remove that check, then it pops up but in the top-left corner of the frame.

+Blink>Forms>Select in case someone who is more familiar with the code can tell us why. Otherwise, I'll keep poking at this tomorrow.

Still able to reproduce the issue on latest beta 58.0.3029.41.
Could you please look into this stable blocker issue.

Thanks,

kenrb@: You looked at a select dropdown OOPIF bug in issue 703191.  Any chance you can offer thestig@ some advice on comment 9?  Just want to make sure we're making progress.

It also sounds like thestig@ is looking at this more than nasko@, so I'll update the ownership.  Thanks!

This has floated back to the top of my queue. Will continue looking.

PrepareFrameAndViewForPrint saves the size of its WebView before resizing it for printing, and restores the original size when finished. It's saving 0x0 for some reason.

c#13: I don't think that is necessarily a problem. In an OOPIF process, with no local main frame to render, WebViewImpl would normally have a size of (0, 0).

Okay, I see the problem, and can take over the bug. As I said, we don't set the size on WebViewImpl because it isn't needed, but we do explicitly set the size on VisualViewport (via RenderWidget::OnResize() -> WebFrameWidgetImpl::resizeVisualViewport() on the OOPIF).

During the print setup it takes the WebViewImpl's size (0, 0), but unfortunately when it restores that size it also overwrites the size in the VisualViewport, which causes the problem in comment 9.

This relates to bug 599688, since sizing isn't in a great state yet. It might make sense to fix these together, which would make WebViewImpl take the right size.

I didn't reply in time, but yes, that 0x0 size is definitely part of the problem. I just didn't know the Blink side well enough to say why, but comment 15 explains it.

A friendly reminder that M58 Stable launch is coming soon! Your bug is labelled as Stable ReleaseBlock, please make sure to land the fix, verified in trunk and get it merged into the release branch ASAP.

A friendly reminder that M58 Stable is launch is coming soon (less than 2 weeks)! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

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

commit 931d158f73d21b37bad43543239a7da2f587ff0e
Author: kenrb <kenrb@chromium.org>
Date: Fri Apr 07 18:18:00 2017

Set WebViewImpl's size in OOPIF processes.

In an OOPIF process with a remote main frame, currently the size of
the WebViewImpl is not set, because it is not relevant when there is
no main frame to render. However, the VisualViewport size is required
so OOPIF resizes set it appropriately.

This has caused a problem during printing because it saves and then
restores the WebViewImpl size, which unfortunately also wipes out the
VisualViewport size. This CL sets the WebViewImpl size along with
the VisualViewport in order to keep them consistent.

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
BUG= 705867 

Review-Url: https://codereview.chromium.org/2801143002
Cr-Commit-Position: refs/heads/master@{#462927}

[modify] https://crrev.com/931d158f73d21b37bad43543239a7da2f587ff0e/third_party/WebKit/Source/web/WebFrameWidgetImpl.cpp

[Auto-generated comment by a script] We noticed that this issue is targeted for M-58; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-58 label, otherwise remove Merge-TBD label. Thanks.

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Your change is approved for M58. Please merge ASAP so that it will be picked up for last Beta Release, RC today(Tuesday-04/11) at 4.00 PM PST.

Note : We will be rolling out for Pre-Stable next week.

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

commit 814a02571cf378f27f0d9e160b284dcc55163b99
Author: Ken Buchanan <kenrb@chromium.org>
Date: Tue Apr 11 21:33:16 2017

Set WebViewImpl's size in OOPIF processes.

In an OOPIF process with a remote main frame, currently the size of
the WebViewImpl is not set, because it is not relevant when there is
no main frame to render. However, the VisualViewport size is required
so OOPIF resizes set it appropriately.

This has caused a problem during printing because it saves and then
restores the WebViewImpl size, which unfortunately also wipes out the
VisualViewport size. This CL sets the WebViewImpl size along with
the VisualViewport in order to keep them consistent.

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
BUG= 705867 

Review-Url: https://codereview.chromium.org/2801143002
Cr-Commit-Position: refs/heads/master@{#462927}
(cherry picked from commit 931d158f73d21b37bad43543239a7da2f587ff0e)

Review-Url: https://codereview.chromium.org/2813983002 .
Cr-Commit-Position: refs/branch-heads/3029@{#669}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/814a02571cf378f27f0d9e160b284dcc55163b99/third_party/WebKit/Source/web/WebFrameWidgetImpl.cpp

Verified the issue on windows 10, Mac 10.12.4 and Ubuntu 14.04 using chrome beta version #58.0.3029.68 as per comment #0.

Observed that "Zoom" drop down menu opened after clicking on it and it did not became unresponsive. Hence, the fix is working as expected.

Attaching screen cast for reference.

Hence, adding the verified labels.

Thanks...!!

Deleted: 705867.mp4 3.6 MB

	705867.mp4 3.6 MB View Download