Let me attach an mp4 version...

Deleted: chrome_bug7.mp4 709 KB

	chrome_bug7.mp4 709 KB View Download

The rendering is correct, but the behavior is just like a bug in IE...

[Correction]

Before:  Does this work in other browsers? N/A
After:    Does this work in other browsers? Yes (Except for IE)

Unable to reproduce the issue on reported chrome canary and equivalent version 71.0.3541.0 using Windows 7 . Attaching screen-cast for reference.
Steps: 
---------
1. Launched reported chrome 
2. Navigated the URL " http://sinst.html.xdomain.jp/zengaku/jkkn/chrome_bug7.html "
As we are able to hover and click on the drop down menu

@Reporter: Could you please check the attached screen cast and please let us know if anything missed from our end and request you to retry this issue with fresh profile without any extensions & apps or reset all the flags and let us know if issue still persists.
Thanks.!

Deleted: 880122.mp4 1.3 MB

	880122.mp4 1.3 MB View Download

Strangely, even in my side, this bug sometimes occurs, and sometimes does not occur.
All flags are set to default state and all extensions are invalidated.

I could not find the condition of occurrence of this bug. Sorry...

Thank you for providing more feedback. Adding the requester to the cc list.

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

As per comment #6 retried the issue on reported chrome canary and equivalent version 71.0.3541.0 using Windows 7 and 10. As we are unable to reproduce the issue from our end. Hence removing Needs-Bisect label to it and requesting some one from Blink Team to look in to it for further triaging it and @Reporter: request you to retry this issue with New Profile without any extensions & apps or reset all the flags.

Thanks..!

Can definitely reproduce this. Seems related to hit testing of the browser plugin perhaps?

wjmaclean@ know of any issues with this code path?

+ kenrb@ - Is this possibly related to the drop-down menu issue you've been investigating?

+ avi@ - Is this possibly related to the work you did with the print-preview with PDFs underneath still responding to events?

My change locked out event processing at the WebContents level when a dialog is up. If you don't have a browser-level dialog, my change shouldn't change anything.

So I just tried out a simple experiment. On the target site in the original report, zoom in the PDF and scroll it so some text is underneath where the popup menu is going to render (I placed it so it would be underneath the "Link 2" menu item.

Pop up the menu, click the left mouse button and drag a bit, then go back and click outside the PDF. You should see that there is text highlighted in the PDF, meaning the hit testing (likely in RenderWidgetHostInputEventRouter in the browser) is routing the mouse events to the PDF.

I don't think this is related to BrowserPlugin, since diagnostic logging in BrowserPlugin::HandleInputEvent fails to register the mouse{down|move|up} events ... as it should (In normal use they are directly routed to the guest view, bypassing the embedder view.)

This suggests to me the async hit testing is somehow missing the CSS popup, and not routing the events to the embedder when it should.

Once Chrome is launched without this bug, it will never occurs again unless I relaunch Chrome.

It seems that the condition of whether the bug occurs changes when Chrome is launched.

The situation is getting worse in Chrome Canary 71.0.3554.0 !!

At first, the bug often disappeared by relaunching Canary. But now,no matter how many times I restart Canary, the bug has ceased to disappear.

If it goes on like this, my office system developed by me will encounter this bug in the future, and a lot of members in my company will be affected ...

* I've already retried this issue with New Profile without any extensions & apps and reset all the flags by "Reset all to default" button on "chrome://flags/"

Hi,
Some of our customers have also been facing this exact same issue in v69.0.3497.100. This was not the case with v68. It seems the issue is if there is an 'absolute' positioned element on top of the iframe, mouse actions bypass the element and go directly to the iframe.

I have the same bug on my chrome version
Version: 69.0.3497.100 (Build officiel) (64 bits)
Extensions: No
Flags reset by default (chrome://flags/)

Whenever an item (div, span, tag...) is above an "embed", "object", or "iframe" tag with a PDF, the item above has no focus.

I also have the same bug where an item above an embed has no focus

OS: Windows 7 Pro x64 build 7601, SP1
Version: 69.0.3497.92 (Build officiel) (64 bits)
Extensions: Disabled

Is there a workaround we can use until this is fixed? Chrome is being auto-updated for a lot of our users and the impact of this issue is increasing.

Same here, we had to urgently deploy a fix (hiding the PDF before displaying the popup) but this is really ugly.

Some of our clients are experiencing this problem on both macOS and windows, in Chrome v69 as well as v70 beta. We can reproduce the issue on some devices, but cannot reproduce the issue on every environment, even with the same OS and Chrome version.

We also deployed a hotfix (hiding the PDF to enable mouse input on overlays)

fsamuel@ - Could you please triage this and see if someone on the viz hittest team can figure out why we're missing this case? Presumably this is a case where we should be doing an async hit-test?

Reassigning to riajiang@, cc'ing sadrul@, rjkroege@.

This looks like a hit testing bug.

More tests scenarios 
 
- Set opacity of Ember to zero, hover works 
- Works on Older Mac book pro Version: 69.0.3497.100 (Build officiel) (64 bits)
- Doesnt Work On the latest Mac book pro with Version: 69.0.3497.100 (Build officiel) (64 bits) 

This makes me feel like its some what related to GU and rendering 

I also have the same bug where an item above an embed has no focus, reported by our users since 2018-09-18

OS: Windows 10 Home x64 build 1803 (OS Build 17134.285)
Version: 69.0.3497.100 (Official Build) (x64)
Incognito Mode
Extensions: Disabled

Further to my report above, the issue became apparent when we opened a modal above an embedded pdf. Only portion of the modal that covered the pdf was unusable (focus was going to the embedded pdf below). Our interim workaround is to move the pdf from the viewport.

Unfortunately, we are unable to reproduce the issue on any test machine, although we had temporary access to an affected customer. The issue was identified by inspecting the affected parts of the modal using dev tools. Dev tools opened the source with the embedded object highlighted. We found that using dev tools to hide the element that rendered the pdf made the modal useable again.

Any steps for creating a test environment would be greatly appreciated.

Hope this helps

Through our own testing, we have been unable to reproduce the issue in MacOS chrome, nor a Chrome install on a Windows Enterprise guest on a Parallels VM. However It was immediately replicated on a personal Windows Home laptop in Incognito mode, and it was reported on at least 2 of our employee laptops running Windows Professional. The VM guests, and the reported users were all using the 64bit version.

During our debugging, we were able to ascertain that setting the display style of the DIV element containing the iframe to hidden, allowed the end user to be able to interact with the elements that were visible, but unavailable for interactions while the PDF was shown.

Our use case is a modal window being opened over the top of the iframe containing the PDF. Not being able to interact with the modal prevents using it as a confirmation dialog. We noticed that the portion of the modal that did not overlay the PDF viewer, was able to be inspected by the development tools. However when attempting to inspect the area of the modal that overlaid the PDF, we found that we were only able to inspect the PDF viewer.

Hello,

Investigation in our company we found out that it depends on chrome app settings.

In windows: %appdata%/local/google/chrome/user data/localstate file there is flag called: 'low_entropy_source2' with values of 930;5362;430 the problem is seen. With other values like 555 the problem is fixed.

stukas.o...@gmail.com's solution worked on my side too. Deleted the property "low_entropy_source2" from "Local State" file and problem is gone.

Can confirm that manually editing the json content of the "Local State" file using a text editor and changing low_entropy_source2 from 

"low_entropy_source2":6983 

to

"low_entropy_source2":555

Solved the situation in the use case I was seeing in the environment:

OS: Windows 10 Home x64 build 1803 (OS Build 17134.285)
Version: 69.0.3497.100 (Official Build) (x64)
Incognito Mode
Extensions: Disabled

 Issue 886906  has been merged into this issue.

Could someone with a repro try disabling "Viz hit-test draw quad" in chrome://flags and see if that fixes the bug?

Additional to my last comment.

I was able to replicate the issue in a VM environment if its any help for testers.

I used a Windows 10 Edge VM provided by the defunct Modern.ie with all recent updates. I edited the Local State file to set low_entropy_source2 to be 6983 and was able to reproduce the reported issue. In my haste to edit the file, I am afraid I did not catch the value that was working prior to changing it to 6983

disabling Viz hit-test draw quad fixed the issue for the machine that reproduces it.

OS: Windows 10 Home x64 build 1803 (OS Build 17134.285)
Version: 69.0.3497.100 (Official Build) (x64)
Incognito Mode
Extensions: Disabled

thanks for verifying! Viz hit-test draw quad is in finch experiment so I'll disable that right now and look into a fix

Some additional information if useful:

Our local devs have been unable to reproduce the bug if the Windows build is less than 1803, specifically (so far) 1709 seems to work without issue.

In our tests, forcing "Viz Hit-test Draw-quad version" to "Enabled" makes this bug happen on any OS apparently. I've attempted this in Arch Linux and was able to reproduce the problem.

Forcing "Viz Hit-test Draw-quad version" to "Disabled" fixes the problem.

OS: Arch Linux, kernel 4.18.7-arch1-1-ARCH SMP PREEMPT x86_64
Version: 69.0.3497.81 (Official Build) (64-bit)
Incognito Mode
Extensions: Disabled

+kylechar@, not sure which channel OOP-D is doing finch experiment in at the point, but since OOP-D implies Viz hit-test (and I can repro with OOP-D turned on), we might want to disable it until this bug is fixed

OOP-D is currently on at 50% in canary/dev/beta for Windows, Linux and Mac. Having an OOPIF that contains an embedded PDF AND then having some web contents overtop of the OOPIF is probably uncommon enough of a case that disabling on canary/dev/beta isn't necessary? The fix should be included in a canary/dev/beta release within the next week.

 Issue 802378  has been merged into this issue.

kenrb@ and wjmaclean@: so this is caused by crbug/802378, since the PDF underneath is a RenderWidgetHostViewGuest, we early return here https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_targeter.cc?sq=package:chromium&g=0&l=159 and doesn't do async path; Viz hit-testing doesn't know about that drop-down menu, so we find the PDF as target and need to rely on the async path to give us the correct result. When we remove the "target->IsRenderWidgetHostViewGuest()" check, the drop-down menu correctly receives the event but then we still have all the problems mentioned in crbug/802378 with PDF

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

commit 325a61c990a18576d6c61a75df0a300684ce4021
Author: Sadrul Habib Chowdhury <sadrul@chromium.org>
Date: Fri Sep 21 18:31:30 2018

viz hit-testing: Fix for BrowserPlugin.

Two notable changes:
 . Do async targeting even if the target is a browser-plugin.
 . Check to see if the hit-test result from blink is a BrowserPlugin,
   and if it is, return the FrameSinkId of that as the target.

BUG= 880122 

Change-Id: I6814161b0795ec2de6f1e28ccb8625008d7b284b
Reviewed-on: https://chromium-review.googlesource.com/1237543
Reviewed-by: James MacLean <wjmaclean@chromium.org>
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org>
Reviewed-by: Ria Jiang <riajiang@chromium.org>
Commit-Queue: Sadrul Chowdhury <sadrul@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593269}
[modify] https://crrev.com/325a61c990a18576d6c61a75df0a300684ce4021/content/browser/renderer_host/render_widget_targeter.cc
[modify] https://crrev.com/325a61c990a18576d6c61a75df0a300684ce4021/content/renderer/browser_plugin/browser_plugin.cc
[modify] https://crrev.com/325a61c990a18576d6c61a75df0a300684ce4021/content/renderer/browser_plugin/browser_plugin.h
[modify] https://crrev.com/325a61c990a18576d6c61a75df0a300684ce4021/content/renderer/input/render_widget_input_handler.cc

Able to reproduce this issue on Windows 10 on the reported version 71.0.3541.0 by enabling the flag #enable-viz-hit-test-draw-quad and the issue is fixed on the latest M-71 build 71.0.3559.0.
Attached is the screen cast for reference. 

Hence adding TE verified labels as the fix is working as intended.

Thanks..

Deleted: 880122-M71.mp4 646 KB

	880122-M71.mp4 646 KB View Download

 Issue 886572  has been merged into this issue.

Requesting merge to M70. (the fix: https://chromium.googlesource.com/chromium/src.git/+/325a61c990a18576d6c61a75df0a300684ce4021) The fix is small and should be safe, it has been on canary for a few days now.

This bug requires manual review: M70 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop)

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

Approved branch:3538

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

Commit: 4a49fa458b8892549b9ead3d78c637a08b7fc71c
Author: sadrul@chromium.org
Commiter: sadrul@chromium.org
Date: 2018-09-27 20:17:49 +0000 UTC

viz hit-testing: Fix for BrowserPlugin.

Two notable changes:
 . Do async targeting even if the target is a browser-plugin.
 . Check to see if the hit-test result from blink is a BrowserPlugin,
   and if it is, return the FrameSinkId of that as the target.

BUG= 880122 

Change-Id: I6814161b0795ec2de6f1e28ccb8625008d7b284b
Reviewed-on: https://chromium-review.googlesource.com/1237543
Reviewed-by: James MacLean <wjmaclean@chromium.org>
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org>
Reviewed-by: Ria Jiang <riajiang@chromium.org>
Commit-Queue: Sadrul Chowdhury <sadrul@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#593269}(cherry picked from commit 325a61c990a18576d6c61a75df0a300684ce4021)
Reviewed-on: https://chromium-review.googlesource.com/1249918
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#710}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}

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

commit 4a49fa458b8892549b9ead3d78c637a08b7fc71c
Author: Sadrul Habib Chowdhury <sadrul@chromium.org>
Date: Thu Sep 27 20:17:49 2018

viz hit-testing: Fix for BrowserPlugin.

Two notable changes:
 . Do async targeting even if the target is a browser-plugin.
 . Check to see if the hit-test result from blink is a BrowserPlugin,
   and if it is, return the FrameSinkId of that as the target.

BUG= 880122 

Change-Id: I6814161b0795ec2de6f1e28ccb8625008d7b284b
Reviewed-on: https://chromium-review.googlesource.com/1237543
Reviewed-by: James MacLean <wjmaclean@chromium.org>
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org>
Reviewed-by: Ria Jiang <riajiang@chromium.org>
Commit-Queue: Sadrul Chowdhury <sadrul@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#593269}(cherry picked from commit 325a61c990a18576d6c61a75df0a300684ce4021)
Reviewed-on: https://chromium-review.googlesource.com/1249918
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#710}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
[modify] https://crrev.com/4a49fa458b8892549b9ead3d78c637a08b7fc71c/content/browser/renderer_host/render_widget_targeter.cc
[modify] https://crrev.com/4a49fa458b8892549b9ead3d78c637a08b7fc71c/content/renderer/browser_plugin/browser_plugin.cc
[modify] https://crrev.com/4a49fa458b8892549b9ead3d78c637a08b7fc71c/content/renderer/browser_plugin/browser_plugin.h
[modify] https://crrev.com/4a49fa458b8892549b9ead3d78c637a08b7fc71c/content/renderer/input/render_widget_input_handler.cc

 Issue 890756  has been merged into this issue.

Able to reproduce the issue on chrome reported version 71.0.3541.0
Verified the fix on Windows-10 Chrome version #70.0.3538.45 as per the comment#0
Attaching screen cast for reference.
Observed "Able to hover and click on the drop-down menu"
Hence, the fix is working as expected.
Adding the verified label.

Thanks!

Deleted: 880122.mp4 939 KB

	880122.mp4 939 KB View Download

 Issue 890308  has been merged into this issue.