DevTools: do not focus source code when breakpoint is hit
Reported by
kgra...@gmail.com,
May 4 2016
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36 Steps to reproduce the problem: 1. Enable break on exceptions 2. Want to inspect things in the console, eg by typing commands 3. Instead focus is in source window What is the expected behavior? I would like to be able to completely disable editing in the source window. I am constantly accidentally typing into the source window when I intend to type into the console What went wrong? I edit stuff in the source window, then have to type undo, and then press escape twice to make the focus go to the console. Did this work before? Yes Before editing was enabled in source window Chrome version: 50.0.2661.94 Channel: stable OS Version: OS X 10.11.4 Flash Version: Shockwave Flash 21.0 r0 I mention this here: http://kyle.graehl.org/javascript/devtools/chrome/2016/04/13/devtools-wishlist.html
,
May 6 2016
In devtools settings under Sources there are already about 13 different settings, 8 checkboxes and two dropdowns. I would suggest adding another option "Enable source editing" Though I guess I can do this myself, I think I saw somewhere that somebody had written an extension to inject code into the devtools.
,
Jun 23 2016
,
Jul 19 2016
,
Jul 20 2016
While I can relate to this issue, adding another setting to already large and intractable list of settings doesn't seem like it'll solve the issue for most people. This seems more like an issue of focus management. Is there any particular reason the source window is gaining focus when the debugger pauses? Are there debugging keyboard shortcuts that are only valid if the editor has focus? If not, I think a better solution would be to not switch focus when the debugger pauses. In this case, if focus was in the console before the exception was raised, it will remain so after. If the Sources panel wasn't active, it could be brought to the foreground and a more benign element (e.g the debugger toolbar) could be given focus.
,
Sep 21 2017
Andrey, what do you think about this?
,
Sep 21
,
Sep 23
Note that 883644 is not about hitting a break point but about simply changing a file externally, in my case with vim... Chrome rudely grabs focus resulting subsequent keystrokes changing the file in Chrome.
,
Jan 7
I think it is a mistake to merge 883644 into this issue - they really aren't the same thing, imo. Please consider 'unmerging' them. |
||||
►
Sign in to add a comment |
||||
Comment 1 by alph@chromium.org
, May 6 2016Owner: l...@chromium.org
Status: Assigned (was: Unconfirmed)