Regressed due to r526154.

--> kenrb@, cc+ riajiang@

This mostly looks like  issue 725830  but I'm not sure if I should dupe it because it sounds like there is additional behavior here that I can't explain.

I wonder if the 'zoom' in step 1 is needed for this bug to repro or not. If it does, perhaps it has something to do with page-scale-factor?

Zoom should not be necessary to repro. If you use the Cast UI this is really obvious and no zooming or moving the PDF is needed, since the Cast dialog is small. I was originally testing with Print Preview, which takes up most of the window, so I needed to get a link to be on the very edge of the page. Zooming was just an easy way to make that happen, rather than searching for a PDF that happened to have a link in the right place.

 Issue 859833  has been merged into this issue.

This is a dup of 725830.

What's happening here is that WebContentsModalDialogManager::BlockWebContentsInteraction only marks the widget of the top-level frame as blocked. It uses RenderWidgetHost::SetIgnoreInputEvents.

We need a way to block an entire page's event processing, no matter how it is put together frame-wise. If you search for RenderWidgetHost::SetIgnoreInputEvents you find it used in three places:

1. The WebContentsModalDialogManager intending to turn off events for a WebContents while there's a dialog up
2. The LoginHandlerViews to *enable* events when it closes (which is weird and almost certainly could be removed to let case 1 handle it)
3. devtool's InputHandler, which uses it to turn event processing on and off per-frame

My initial thought re SetIgnoreInputEvents was to entirely remove it, and put a switch into the WebContents. RenderWidgetHostImpl::ShouldDropInputEvents() then calls out to its RenderWidgetHostDelegate, which is the WebContentsImpl, which can check to see if it's in a state of ignoring events.

But the InputHandler is what I don't know about. It seems that devtools offers the ability to turn off input events per-frame (as per InputHandler::SetIgnoreInputEvents). If I can't remove RenderWidgetHost::SetIgnoreInputEvents entirely, perhaps I can remove it from the content public interface?

That's my plan; without objections I will fix this.

Taking.

 Issue 725830  has been merged into this issue.

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

commit 738ea19831a4395bff3066a8ce994482ac8b44d6
Author: Avi Drissman <avi@chromium.org>
Date: Wed Aug 29 20:24:16 2018

Move the public "ignore events" switch to WebContents.

All public users intend to set "ignore events" on an entire
page, but the API was on widget and so it was only ever set
on the top-level widget. Move it to WebContents to allow it
to have the desired effect.

BUG= 863582 ,  725830 

Change-Id: I435b9f93160d0d77ad1aa0919757a4acd933768e
Reviewed-on: https://chromium-review.googlesource.com/1194484
Reviewed-by: Mike Wittman <wittman@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587274}
[modify] https://crrev.com/738ea19831a4395bff3066a8ce994482ac8b44d6/chrome/browser/ui/views/login_handler_views.cc
[modify] https://crrev.com/738ea19831a4395bff3066a8ce994482ac8b44d6/components/web_modal/web_contents_modal_dialog_manager.cc
[modify] https://crrev.com/738ea19831a4395bff3066a8ce994482ac8b44d6/content/browser/renderer_host/render_view_host_impl.cc
[modify] https://crrev.com/738ea19831a4395bff3066a8ce994482ac8b44d6/content/browser/renderer_host/render_widget_host_delegate.cc
[modify] https://crrev.com/738ea19831a4395bff3066a8ce994482ac8b44d6/content/browser/renderer_host/render_widget_host_delegate.h
[modify] https://crrev.com/738ea19831a4395bff3066a8ce994482ac8b44d6/content/browser/renderer_host/render_widget_host_impl.cc
[modify] https://crrev.com/738ea19831a4395bff3066a8ce994482ac8b44d6/content/browser/renderer_host/render_widget_host_impl.h
[modify] https://crrev.com/738ea19831a4395bff3066a8ce994482ac8b44d6/content/browser/renderer_host/render_widget_host_view_aura.cc
[modify] https://crrev.com/738ea19831a4395bff3066a8ce994482ac8b44d6/content/browser/web_contents/web_contents_impl.cc
[modify] https://crrev.com/738ea19831a4395bff3066a8ce994482ac8b44d6/content/browser/web_contents/web_contents_impl.h
[modify] https://crrev.com/738ea19831a4395bff3066a8ce994482ac8b44d6/content/public/browser/render_widget_host.h
[modify] https://crrev.com/738ea19831a4395bff3066a8ce994482ac8b44d6/content/public/browser/web_contents.h

Unable to reproduce the issue on reported version 67.0.3396.87 on Ubuntu 17.10 by following below steps.
Note : The file used for testing is taken from issue id :725830
1.Launched chrome 
2.Opened a PDF with some links.
3.Opened print preview.
4.Tried clicking the link in the pdf print preview, observed that links does not work 

Attached the screencasts for reference.
avi@ - Could you please check the screencasts and help us in verifying the fix, let us know if anything is being missed from our end.

Thanks.!

Deleted: 863582_M67.webm 6.5 MB

	863582_M67.webm 6.5 MB View Download

Deleted: 863582_M70.webm 4.5 MB

	863582_M70.webm 4.5 MB View Download

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

commit c2618c04a51d4b3aa8d07056f70054628e2413f6
Author: Avi Drissman <avi@chromium.org>
Date: Thu Aug 30 14:12:57 2018

DevTools: Use new page-wide API for ignoring input

The new API for ignoring input is on the WebContents. Given
that the exposed devtools protocol says that it disables
input events on the page, use the new API.

This removes the last user of the widget-level ignore flag
so it removes the flag as well.

BUG= 863582 

Change-Id: I2602f1c1d86bd4d73e7877e708d0eb201048ff2d
Reviewed-on: https://chromium-review.googlesource.com/1195833
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587558}
[modify] https://crrev.com/c2618c04a51d4b3aa8d07056f70054628e2413f6/content/browser/devtools/protocol/input_handler.cc
[modify] https://crrev.com/c2618c04a51d4b3aa8d07056f70054628e2413f6/content/browser/renderer_host/render_widget_host_impl.cc
[modify] https://crrev.com/c2618c04a51d4b3aa8d07056f70054628e2413f6/content/browser/renderer_host/render_widget_host_impl.h
[modify] https://crrev.com/c2618c04a51d4b3aa8d07056f70054628e2413f6/content/browser/renderer_host/render_widget_host_unittest.cc

Re comment 14, here's an easier way to verify.

1. Load a PDF.
2. In the omnibox, type (do not paste) "javascript:alert()" (do not type the quotes)
3. A dialog will appear; leave it up
4. Attempt to interact with the PDF while the dialog is up.

> This should be different; with the fix the PDF should not react to anything you do in step 4