Bisect info: 469563 (good) - 469575 (bad)
https://chromium.googlesource.com/chromium/src/+log/82cbc419..ba9abc4c?pretty=fuller
Suspecting r469568 "[DevTools] Enable "auto attach to sub frames" by default"
Landed in 60.0.3091.0

Repro: test case extension is attached. Install it and follow the displayed instructions.
EXPECTED: able to select the element
OBSERVED: not able to select the element

Deleted: test-extension.zip 1.2 KB

test-extension.zip 1.2 KB Download

Deleted: good.png 16.4 KB

	good.png 16.4 KB View Download

Deleted: bad.png 12.3 KB

	bad.png 12.3 KB View Download

To reiterate the obvious just in case: extension iframes aren't handled the same as web iframes and don't get a devtools attached internally.

Thanks for the report, and thanks for the bisect.  I can repro this bug on commit #469569.  dgozman@, could you please take a look?

Hmm... This is overlay not working for OOPIFs properly. I remember we fixed that, perhaps it did break? I'll take a look.

So, this is definitely OOPIF problem. Usually, mouse move events go to child frame's WebFrameWidgetImpl and being handled there. But with DevTools overlay things change:
- Main frame instantiates a PageOverlay instance, which adds a layer [1]. Not doing so makes the problem disappear.
- This layer somehow prevents mouse move events to be first dispatched to child frame's WebFrameWidgetImpl.
- Instead, events go directly to main frame's WebViewImpl and get handled there.
- Child frame's PageOverlay doesn't affect the picture - I tried disabling it.

dcheng@, kenrb@, do you have any idea why extra layer affects the input events routing for OOPIF?

[1] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/page/PageOverlay.cpp?rcl=c3a1e507c5ecd4c3dfcd550d6e884873222e6d10&l=64

I believe this would be because the browser process is looking at which renderer process should receive the mouse event, and sees the main frame is painting something over top of the iframe, and decides that means the main frame should be the target of the event.

This is a specific case of a known issue with our current hit testing system, and while we have a long term plan to resolve it (a new system is being built for the viz service), we hadn't actually seen any significant regressions from it until now. We have a way to make the browser-side event router ignore frames that have pointer-events:none, but AFAIK there isn't a similar mechanic to make it ignore a layer.

We might be able to build something to do that in the shorter term. Usually this isn't a problem because if an element is drawing over top of a cross-site iframe, no mouse events can be targeted to that iframe. If I understand correctly, the issue here is that we are painting a layer that doesn't correspond to anything in the DOM.

> If I understand correctly, the issue here is that we are painting a layer that doesn't correspond to anything in the DOM.
Correct. What you describe here matches my understanding of how overlay works.

Tentatively assigning to kenrb@ as I don't see anything I can do.

 Issue 775401  has been merged into this issue.

Issue 800832 has been merged into this issue.

Ken, is there anything we can do short-term and/or from our side? More user reports are coming.

@vollick, gklassen: can we apply a temporary fix from https://bugs.chromium.org/p/chromium/issues/detail?id=788807#c12 here as well?

This is fixed on trunk as a result of the work on  issue 796651 . None of that is mergeable to M64, unfortunately, but M65 hasn't branched yet so that should carry the fix.

We couldn't find any easy fixes for this problem that we'd be able to merge to an earlier release because it is considerably more complicated than the layer squashing bug.

Thanks, that sounds great! I think it's fine to not merge to M64 given the situation.

Issue 800966 has been merged into this issue.

>This is fixed on trunk as a result of the work on  issue 796651 

Not really: right-clicking an element and choosing "Inspect" does not open that element in devtools even in Chrome 66. One has to use element picker from within devtools to click that element while the entire page is being overlayed with a blue background hindering selection process. I hope nobody thinks this is WAI as it's obviously a huge regression in usability from the historical behavior.

Er, correction. This issue is indeed fixed in Chrome 66, but not the complementary issue about rightclick + Inspect inside an iframe. Was it even reported?

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

commit 902bffab618a622ed802ff3b1cfe5647d2687191
Author: Dmitry Gozman <dgozman@chromium.org>
Date: Sat Jan 27 15:20:46 2018

[DevTools] Make Inspect Element work for OOPIF

To support this, we issue inspect element command to the agent
beforehand, and dispatch it in the next session which attaches
(or the existing one if any). This moves InspectElement from
DevToolsSession interface to DevToolsAgent interface, as there
might be no session yet.

Note this could fail in case of multiple sessions, one of which is
DevTools frontend, by choosing the wrong one. This is a rare
case though, so we can tolerate that.

TBR=alexclarke@chromium.org

Bug:  755515 ,  804100 
Change-Id: I331bfb7f5410868fd47bfe8d558b54b7a30de00c
Reviewed-on: https://chromium-review.googlesource.com/881522
Reviewed-by: Alex Clarke <alexclarke@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Commit-Queue: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#532220}
[modify] https://crrev.com/902bffab618a622ed802ff3b1cfe5647d2687191/chrome/browser/devtools/devtools_sanity_browsertest.cc
[modify] https://crrev.com/902bffab618a622ed802ff3b1cfe5647d2687191/chrome/browser/devtools/devtools_window.cc
[add] https://crrev.com/902bffab618a622ed802ff3b1cfe5647d2687191/chrome/test/data/devtools/oopif.html
[add] https://crrev.com/902bffab618a622ed802ff3b1cfe5647d2687191/chrome/test/data/devtools/oopif_frame.html
[modify] https://crrev.com/902bffab618a622ed802ff3b1cfe5647d2687191/content/browser/devtools/devtools_agent_host_impl.cc
[modify] https://crrev.com/902bffab618a622ed802ff3b1cfe5647d2687191/content/browser/devtools/devtools_agent_host_impl.h
[modify] https://crrev.com/902bffab618a622ed802ff3b1cfe5647d2687191/content/browser/devtools/devtools_session.cc
[modify] https://crrev.com/902bffab618a622ed802ff3b1cfe5647d2687191/content/browser/devtools/devtools_session.h
[modify] https://crrev.com/902bffab618a622ed802ff3b1cfe5647d2687191/content/browser/devtools/render_frame_devtools_agent_host.cc
[modify] https://crrev.com/902bffab618a622ed802ff3b1cfe5647d2687191/content/browser/devtools/render_frame_devtools_agent_host.h
[modify] https://crrev.com/902bffab618a622ed802ff3b1cfe5647d2687191/content/public/browser/devtools_agent_host.h
[modify] https://crrev.com/902bffab618a622ed802ff3b1cfe5647d2687191/content/shell/browser/shell_devtools_bindings.cc
[modify] https://crrev.com/902bffab618a622ed802ff3b1cfe5647d2687191/headless/public/util/testing/mock_devtools_agent_host.h
[modify] https://crrev.com/902bffab618a622ed802ff3b1cfe5647d2687191/third_party/WebKit/Source/core/exported/WebDevToolsAgentImpl.cpp
[modify] https://crrev.com/902bffab618a622ed802ff3b1cfe5647d2687191/third_party/WebKit/Source/core/exported/WebDevToolsAgentImpl.h
[modify] https://crrev.com/902bffab618a622ed802ff3b1cfe5647d2687191/third_party/WebKit/Source/devtools/front_end/Tests.js
[modify] https://crrev.com/902bffab618a622ed802ff3b1cfe5647d2687191/third_party/WebKit/Source/devtools/front_end/elements/ElementsPanel.js
[modify] https://crrev.com/902bffab618a622ed802ff3b1cfe5647d2687191/third_party/WebKit/public/web/devtools_agent.mojom

 Issue 816468  has been merged into this issue.

 Issue 816455  has been merged into this issue.

There seems to be an issue showing up in chrome 66 that might be related to this fix.

I'm currently running this build:
Version 66.0.3359.33 (Official Build) beta (64-bit)

If you side load the test extension attached with this issue, the first time you try to right click and inspect something inside the iframe, it will open dev tools and an element in the contents of the iframe will be selected properly.

However, if you then navigate to another tab (or just create a new tab) then come back to the tab where the extension is open, you can no longer right click on the iframe to get the context menu.  In fact, it looks like no mouse events are being captured in the iframe at all (you cannot highlight text or click on anything inside the iframe).

Once you get in this state of not being to click on the iframe, you can only recover if you resize the browser window.

I also tested this on Version 65.0.3325.162 (Official Build) (64-bit) and it does not happen there.

 

Comment 24: From the discussion on  issue 823405 , it sounds like this has been fixed in  issue 822442 .