New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 808879 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Feature



Sign in to add a comment

Feature: Stop Auto-opening the Call Stack

Reported by aneil.ma...@gmail.com, Feb 4 2018

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36

Steps to reproduce the problem:
Opening the call stack automatically every time the debugger starts is annoying. Opening the call stack means the Locals aren't visible, so every single time, the developer needs to close the call stack after starting the debugger, which is annoying.

For example, see: https://groups.google.com/forum/#!topic/google-chrome-developer-tools/sll_xyjJaSQ

Two possible fixes: 
1. don't auto-open
2. remember last state
3. move call stack below Locals

To reproduce
1. Make file.js with contents "debugger"
2. node file.js --inspect-brk
3. chrome debugger opens with call stack open
4. click the call stack to hide it
5. debug again
6. The call stack view is visible again

What is the expected behavior?

What went wrong?
Call stack always opens when debugger starts

Did this work before? N/A 

Chrome version: 64.0.3282.140  Channel: stable
OS Version: OS X 10.13.2
Flash Version:
 
Screen Shot 2018-02-04 at 10.20.43 AM.png
131 KB View Download
Thanks for filing the issue!

As per comment#0 by the reporter this seems to be a feature request hence marking it as Untriaged.
Cc: viswatej...@techmahindra.com
Labels: -Type-Bug Triaged-ET M-66 FoundIn-66 Target-66 Needs-Triage-M64 OS-Linux OS-Windows Type-Feature
Status: Untriaged (was: Unconfirmed)
Owner: kozy@chromium.org
Status: Assigned (was: Untriaged)
Seriously, I can't be the only person in the world irritated by this behavior. 
Owner: l...@chromium.org
We need some heuristics in order to fix this.
There is no way to strictly distinguish the breakpoint or exception stop from the stepping...
Labels: -Needs-Triage-M64 Needs-Feedback
I'm unable to reproduce this while stepping.  After collapsing the Call Stack manually, stepping preserves the closed state during the entire DevTools session.  Are people still able to repro this on Canary?

I am able to reproduce in these cases:
- closing and reopening DevTools
- resizing DevTools to trigger the layout switch between vertical / horizontal (debugger sidebar becomes drawer)

In these cases, we entirely forget the closed state, and it seems reasonable to address those, but I'd like to confirm these.

Sign in to add a comment