DevTools: Console frame should default to Top
Reported by
cont...@ehsankia.com,
May 22 2016
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.54 Safari/537.36 Steps to reproduce the problem: 1. Go to a page with multiple iframes 2. Open console with F12 or ctrl+shift+j 3. Look at the frame selected What is the expected behavior? Frame should be set to "top" What went wrong? Sometimes, some other frame is selected Did this work before? Yes chrome 49 (not entirely sure on this one) Chrome version: 51.0.2704.54 Channel: beta OS Version: 10.0 Flash Version: Shockwave Flash 21.0 r0 My main issue with this is how inconsistent it seems to be. Every time I go to try something in console, half the time it will be the right frame, and half the time it'll be some random frame. I don't see a reason to use any other frame by default than top.
,
May 23 2016
Upon further testing, when I first open DevTools using F12, some random frame is selected, but as soon as I select the Inspect tab, it automatically jumps to "top" frame.
,
May 23 2016
,
May 23 2016
I think this is a feature which restores selected frame to the last selected one from previous DevTools session. Does this distract you? Do you observe different behavior? When you click to Elements tab, we sync selected frame with selected element in the DOM (which is top in your case).
,
May 23 2016
There seems to definitely be a bug with this feature then, and it seems to be related to extensions. I think I figured it out. Here is my repro: 1. Switch your DevTools tab to "console" and close dev tools. 2. Have an extension installed that works while you're on a page* 3. Open Devtools with F12 Expected result: frame is set to top Actual result: frame is set to that extension *: For example, I have "Comment Save" which automatically saves things I type in an input, such as this message I'm writing right now. Another example Would be Tamper Monkey with on a page that has an active script. Now, in most cases, that extension is a child of the "top" frame and everything is fine. But sometimes, in pages with multiple frames, the /last/ action will be from an extension on another frame, and you end up with that when you open DevTools. This explains the "pseudorandom" nature of this bug.
,
May 23 2016
Thanks for detailed explanation. I think we should try to stick with top unless we specifically restore last selection. We'll look into fixing this.
,
May 25 2016
Reproducible on Chrome 53.0.2747.0 on OS X 10.11.5. I agree we should stick with the top frame. How about we make restoring last selection an option in console settings?
,
May 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9ba33beabdf47d80c723b4af670df825077be80f commit 9ba33beabdf47d80c723b4af670df825077be80f Author: dgozman <dgozman@chromium.org> Date: Thu May 26 00:41:48 2016 [DevTools] Stick with top frame unless user selected something else. BUG= 613878 Review-Url: https://codereview.chromium.org/2009903002 Cr-Commit-Position: refs/heads/master@{#396058} [modify] https://crrev.com/9ba33beabdf47d80c723b4af670df825077be80f/third_party/WebKit/LayoutTests/http/tests/inspector/workspace-test.js [modify] https://crrev.com/9ba33beabdf47d80c723b4af670df825077be80f/third_party/WebKit/LayoutTests/inspector/sources/debugger-ui/last-execution-context-expected.txt [modify] https://crrev.com/9ba33beabdf47d80c723b4af670df825077be80f/third_party/WebKit/LayoutTests/inspector/sources/debugger-ui/last-execution-context.html [modify] https://crrev.com/9ba33beabdf47d80c723b4af670df825077be80f/third_party/WebKit/Source/devtools/front_end/components/ExecutionContextSelector.js
,
May 26 2016
Should be fixed now. Please try it out in Canary. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by l446240525@gmail.com
, May 23 2016