Devtools console shortcut (Esc) is inconsistent when used in an extension's tab
Reported by
sid...@ucode.com,
Oct 8 2017
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce the problem: 1. Open the Chrome Devtools 2. Open a tab added by an extension (for example, the React tab from the react developer tools) 3. Hit "Escape" to open/close the conosle If the console drawer is open, it closes as expected. However, if the drawer is closed, it flashes up for just a moment. Holding "Esc" makes the drawer flash open and closed. If you release "Esc" at the right time, the console drawer will stay open. What is the expected behavior? The console drawer opens when the escape key is pressed one time. What went wrong? After spending way too long investigating this, I discovered the keydown event from hitting the escape key is untrusted (`isTrusted: false`) by the top level window object when hitting escape. The event *is* trusted when closing it. The event is always trusted by the *extension's tab window*. The keydown event is fired twice when opening (both are untrusted) and once one closing. It appears to be untrusted by the top level window because it the event is created here: https://github.com/ChromeDevTools/devtools-frontend/blob/master/front_end/extensions/ExtensionServer.js#L652 (You can confirm this by adding a *capturing* listener to the top level window of the devtools that listens for keydown events that logs the event; the stack trace indicates that line of that file) window.addEventListener('keydown', console.log, true) Perhaps this is related to how the sandbox around the extension panel transfers events up to the top level window? Did this work before? Yes Chrome version: 61.0.3163.100 Channel: stable OS Version: 10.0 Flash Version: I've reproduced this on the latest version of Chrome on Windows 10 and Mac OS (not sure which version). I do not remember this being an issue until very recently, so it could have been introduced in a recent update. However I cannot point to a specific version of Chrome. It also might be worth noting that the console drawer works perfectly fine in the native Devtools tabs.
,
Oct 9 2017
,
Oct 9 2017
Able to reproduce the issue on Windows 10 and mac 10.12.6 using chrome reported version #61.0.3163.100 and latest canary #63.0.3235.0. Unable to reproduce the issue on Ubuntu 14.04 using chrome latest stable #61.0.3163.100 but able to reproduce using latest chrome version #63.0.3236.0. Bisect Information: ===================== Good build: 61.0.3133.0 Revision(480259) Bad Build : 61.0.3134.0 Revision(480301) Change Log URL:(from per-revision script) https://chromium.googlesource.com/chromium/src/+log/77ddcddc4b0adad18246c1bea3 Note: Got more than 100 suspects from the above change log. Hence, providing the suspect from changelog from omahaproxy. Change Log URL: (From Omahaproxy) https://chromium.googlesource.com/chromium/src/+log/61.0.3133.0..61.0.3134.0?pretty=fuller&n=10000 From the above change log from omahaproxy suspecting below change Review url: https://codereview.chromium.org/2935393002 chenwilliam@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Note: Adding label ReleaseBlock-Stable as it seems to be a recent regression. Please feel free to remove the same if not appropriate. Thanks...!!
,
Oct 9 2017
Changing the milestone to M62 as it is reproducible on latest beta #62.0.3202.45 as well. Thanks...!!
,
Oct 9 2017
Since at the moment we aren't planning any M61 refreshes, please get the fix into M62.
,
Oct 9 2017
This is unrelated to my change: https://codereview.chromium.org/2935393002 Let's leave this untriaged so the DevTools sheriff can assign this.
,
Oct 9 2017
chenwilliam@, reverting your change in resources.pak fixes the bug so it's definitely related even if the underlying cause is different.
,
Oct 9 2017
OK, sorry I missed out on the first comment. Doesn't seem like ReleaseBlock-Stable.
,
Oct 9 2017
I bisected it into a different range: https://chromium.googlesource.com/chromium/src/+log/25149208ab460c968e74de1fe9b31f6f5cbfce7f..963683348d7aaf16b7804b848c0f154f19cbdd15 Suspecting "DevTools: flip devtools extensions to load out of process." https://chromium.googlesource.com/chromium/src/+/28010fcf09d929d2598531c0d141bfe61e7ea8c7
,
Oct 10 2017
Thanks @alph - Assigned it to @pfeldman since it seems more likely to have caused this regression than my change.
,
Dec 28 2017
The underlying cause is this: https://bugs.chromium.org/p/chromium/issues/detail?id=798019 I'll work around it for now.
,
Jan 3 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/81504ef63932f7ad2af235f44f59e37165b7430d commit 81504ef63932f7ad2af235f44f59e37165b7430d Author: Dmitry Gozman <dgozman@chromium.org> Date: Wed Jan 03 20:17:51 2018 DevTools: only inject extensions API once. Bug: 772697 Change-Id: Ic8f75ef3970aeaa0c7f968957873898fd12c7137 Reviewed-on: https://chromium-review.googlesource.com/846341 Commit-Queue: Dmitry Gozman <dgozman@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#526783} [modify] https://crrev.com/81504ef63932f7ad2af235f44f59e37165b7430d/third_party/WebKit/LayoutTests/http/tests/devtools/extensions/extensions-api-expected.txt [modify] https://crrev.com/81504ef63932f7ad2af235f44f59e37165b7430d/third_party/WebKit/Source/devtools/front_end/extensions/ExtensionAPI.js
,
Jan 9 2018
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by woxxom@gmail.com
, Oct 8 2017