carloto.dev@ Thanks for the issue.

For the better understanding of the issue can you please provide us the screen cast where you are seeing this issue, which will help us in further triaging.

Thanks..

susanjuniab@, here's the screen cast you requested.

Anything else you need let me know.

Thanks

Deleted: dev_tools_unresponsive.mp4 8.0 MB

	dev_tools_unresponsive.mp4 8.0 MB View Download

Thank you for providing more feedback. Adding requester "susanjuniab@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Tested the issue on Win-10 using chrome latest stable #62.0.3202.75.

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Installed Marionette Inspector extension.
2. Set the auxiliary display to 100% and primary display to 150% as in the attached screen cast.
3. Set chrome dev tools on right docking mode.
4. Opened chrome dev tools while the browser is in the auxiliary display.
5. Observed that the UI was unresponsive when docked to left or to right. Even on primary display the extension UI was unresponsive.

carloto.dev@ - Could you please check the screen cast and please let us know if anything missed from our side.

Thanks...!!

Deleted: 778443.mp4 3.7 MB

	778443.mp4 3.7 MB View Download

Hi krajshree@

Looking at your video, my guess is that you may not have clicked on the "Start Inspector" button of the Marionette extension. 
Only after clicking that button (that will be gone afterwards) the remaining options on the extension UI header will become responsive. But that's a specificity of this particular extension usage and not related with the present issue.
I tested again, with the Marionette extension, and on right docking mode even the "mouseover" effect on the "Start Inspector" button will not work. On left side docking mode I did not have such problems.

Any further clarification let me know.

Thanks

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Tested the issue on windows 10 with the steps mentioned in comment #6 & #7  on chrome stable M62 #62.0.3202.89 and observed the similar behavior as in comment #6.

Attached screencast for reference.

#Extension UI is unresponsive in both the windows (auxiliary & primary) even after clciking the "start Inspector".

@ carloto.dev-- Could you please check in latest chrome stable with fresh profile without any extensions and flags enabled and update us with your observations.

Thanks!

Deleted: 778443.mp4 4.0 MB

	778443.mp4 4.0 MB View Download

Hi, hdodda@

Tested again with the latest chrome version and with all other extensions disabled. I still don't have issues on the primary screen, only the auxiliary.

1. First tested on auxiliary display on left side docking mode, to demonstrate I had no issues.
2. Closed dev tools and opened it again on auxiliary display on right side docking mode, to demonstrate the extension was unresponsive.
3. Dragged the browser to the primary display to demonstrate that the problem was gone.

I'm unaware of the reason why the problem is even worst in setups other than mine. I could guess something to do with screen resolution, but I'm unable to confirm it on my side.

Also I would like to remember that this issue is common to all dev tools extensions that I've tested so far, not just this particular one.

Please let me know what is missing to change this ticket to the confirmed status.

Thanks!

Deleted: Recording #3.mp4 2.9 MB

	Recording #3.mp4 2.9 MB View Download

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Thanks for the report.  @original reporter: when extensions become unresponsive to mouse clicks, are they also responding to keyboard navigation? (e.g. tabbing / focus)

caseq@, do you know if key/mouse inputs to DevTools extensions are handled differently somehow?

Possibly a dupe, not sure yet  https://crbug.com/781531 

I can still do keyboard navigation (tab, enter) in a scenario where the dev tools extension is unresponsive to mouse clicks. 
Tested with the Marionette inspector.

I was having similar issues as those above. The dev tools were unresponsive on my auxiliary monitor but responsive on my laptop monitor.  I was able to make them responsive by undocking the dev tools into a separate window and was receiving feedback responses when using keyboard navigation (tabbing).

I found that resetting my second monitor's display scale from the setting menu was providing a temporary fix (until I closed the Chrome window on my second monitor and reopened it, at which point it became unresponsive again).  However when I disabled all of my extensions, in preparation for the screencast and added the Chrome Robot, this bug seemed to disappear completely.  Of course now I can't reproduce it and the extensions (React Developer Tools and Chrome Robot) seem to work perfectly...

I am using a 2016 Windows XPS 15 with 4k resolution and a 17' HP Pavilion  an auxiliary monitor.

Scratch that, the issue persisted after a full restart:

Deleted: Chrome-Dev-Tools.mp4 920 KB

	Chrome-Dev-Tools.mp4 920 KB View Download

DevTools extensions are in an out-of-process iframes, so I think this is a combination of OOPIF and having different device scale factors between two monitors, so that we end up routing mouse events to a wrong iframe because we have wrong DPR. Pavel managed to reproduce this locally, here's a refined repro:

1. Open chrome on one monitor (e.g. one with scale of 150%)
2. Open DevTools
3. Switch to the extension panel
4. Undock devtools
5. Drag it to another monitor (e.g. that with the scale of 100%)
6. Observe the effect of scale change (smaller fonts etc).
7. Dock DevTools
8. Observe the scale in the extension panel is still that of a secondary monitor (i.e. small fonts), while the DevTools menu is appropriately scaled
9. Observe mouse events are not routed to the extension panel

Thanks for the report!  wjmaclean@, can you take a look?  This sounds similar to one you've mentioned before, I think.

This looks suspiciously like https://bugs.chromium.org/p/chromium/issues/detail?id=659642

Can someone try disabling chrome://flags/#enable-use-zoom-for-dsf and seeing if the issue persists?

>> Can someone try disabling chrome://flags/#enable-use-zoom-for-dsf and seeing if the issue persists?

It persists, this looks like a separate issue. dsf is not being updated for that iframe upon devtools dock / undock.

There are repro steps for the MacOS as well:

- Open Chrome window and devtools on your Retina display
- Navigate to https://reactjs.org/community/examples.html
- Drag Chrome window to the non-retina secondary monitor
- Open "React" tab in DevTools

You'll see that only 50% of the corresponding iframe renders.

OK - (for me) the issue seems to happen only in a Chrome Window that has been opened by the Visual Studio (2017) debugger .. The same page works fine in a separate Chrome instance that is not connected to the debugger.

Re c#22, I don't think any of the other reports have involved anything not rendering, have they? Lack of rendering isn't necessarily going to be a lack of DSF getting sent to the OOPIF, but possibly entirely wrong geometry being sent (the latter happens in a different pathway).

 Issue 781531  has been merged into this issue.

Since this doesn't appear to be a regression issue, I'm going to remove the RB label. I'll still try and figure this out ASAP, but no guarantees it will happen in time for stable release.

I'm trying to follow the repro instructions, and I can't get Marionette to work at all, regardless of which monitor I use. When I click "Start Inspector" nothing happens, and I get the following console messages:

[3798:3798:1204/105527.832447:ERROR:CONSOLE(18966)] "Uncaught TypeError: Cannot read property 'push' of undefined", source: chrome-extension://fbgfjlockdhidoaempmjcddibjklhpka/panel.html (18966)
[3798:3798:1204/105528.011902:ERROR:CONSOLE(4889)] "Cannot find context with specified id", source: chrome-devtools://devtools/bundled/inspector.js (4889)
[3798:3798:1204/105528.011985:ERROR:CONSOLE(7317)] "Extension server error: Inspector protocol error: Cannot find context with specified id", source: chrome-devtools://devtools/bundled/inspector.js (7317)
[3798:3798:1204/105528.012833:ERROR:CONSOLE(55)] "Uncaught undefined", source: chrome-extension://fbgfjlockdhidoaempmjcddibjklhpka/js/inspector/client/inspectedPage.js (55)
[3798:3820:1204/105528.474348:ERROR:service_manager.cc(158)] Connection InterfaceProviderSpec prevented service: content_renderer from binding interface: blink::mojom::ReportingServiceProxy exposed by: content_browser

I was trying to inspect github.com, as in the examples.

I've done this in a fresh profile, with no other extensions installed. Until I can get Marionette to work properly, it will be impossible to reproduce the failure.

I should mention, I'm testing with 65.0.3285.0.

Hi  wjmaclean@

As mentioned previously, this issue is not specific to a given dev tools extension.
The original report includes a list of examples of chrome dev tools extensions where I could reproduce the problem (other than Marionette).

I just reconfirmed the issue on the last stable production version for Windows (63.0.3239.84)

fsamuel@ revised how DSF gets routed to OOPIFs in https://chromium-review.googlesource.com/721851 on Oct 17th, which is just before this issue was reported.

I don't think this particular CL caused the issue given #0 states this is a stable build of Chrome and my patch landed tip of tree on Oct 17. With that said, I have been tweaking device scale factor plumbing over the last little while so it's possible I caused this regression. I'll try to repro.

I was mostly thinking that, regardless of how it regressed (if indeed it did), you currently know the pathways for DSF better than I do. :-)

>Since this doesn't appear to be a regression issue

I'm not quite sure what counts as a regression in Chromium tracker terminology, but I wanted to mention it's definitely a new issue and started happening around September 2017. If it existed before our users would have reported it a long time ago, as it's very disruptive.

A fix is coming today.

This should be fixed.