794886 - Avoid confusion caused by accidentally prefing off the panels

Status: RESOLVED FIXED

(DevTools :: Debugger, enhancement, P3)

Comment 1

[Victor Porof [:vporof][:vp]]

So, in a nutshell, the problem is that the debugger panes get automatically shown when the first breakpoint is hit (being hidden by default when the debugger is started). It may be a good idea to draw the users' attention to the toggle button, since there are two paths that can be taken:

Path 1:
1] debugger opened with panes closed
2] breakpoint hit
3] panes are shown
4] user closes debugger
5] loop

No unexpected behavior there, panes are always reshown when a breakpoint is hit, however:

Path 2:
1] debugger opened with panes closed
2] breakpoint hit
3] panes are shown
4*] user collapses the panes by clicking the button (maybe by accident), hence basically stating that "I don't want to see these panes by default ever"
4] user closes debugger
5] redo 1]
6] redo 2]
7] panes are not automatically shown

If the user forgot about the toggle button, all hope is lost.

During the London meetup, Brian suggested that the be(st|tter) approach would be to move the toggle button on the right and skin it just like the play/step buttons. This way, maybe it will draw more attention onto it.

Another idea would be to use a doorhanger panel over the toggle button, informing about what it does, but I really dislike the potential "walkthrough"ish or "tutorial"esque feeling given by this approach.

If we are going to skin the toggle button like the play/step buttons and move it on the right, I'm going to need the blue checked state of the icons. I'm still not 100% convinced this is the best thing to do, however.

I may also be too paranoid about users forgetting what buttons do :)
Feedback/opinions required.

Comment 2

[Victor Porof [:vporof][:vp]]

Attachment: v1

Ok, I've been thinking about this and I think it's actually a bad idea to have the panes not show up in some cases.

It's probably counter-intuitive to have this behavior in the first place. Clicking the 'toggle panes' button to hide them doesn't mean "I never want to see these panels ever again". By removing this behavior, all the problems described above disappear, and there's no need to change the UI.

Comment 3

[Panos Astithas (he/him) [:past] (please ni?)]

Comment on attachment 674185 [details] [diff] [review]
v1

Review of attachment 674185 [details] [diff] [review]:
-----------------------------------------------------------------

Agreed, this is not confusing, although some users may be annoyed that they can't persist their preference for always open side panes. Wait, they can already do that by flipping the stackframes/variables-pane-visible prefs, right?

Moving the toggle and close buttons on the right may still make sense, though, but we can leave that for the toolbox refactoring.

Comment 4

[Victor Porof [:vporof][:vp]]

(In reply to Panos Astithas [:past] from comment #3)
> Comment on attachment 674185 [details] [diff] [review]
> v1
> 
> Review of attachment 674185 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Agreed, this is not confusing, although some users may be annoyed that they
> can't persist their preference for always open side panes. Wait, they can
> already do that by flipping the stackframes/variables-pane-visible prefs,
> right?
> 

Not yet, the prefs work just as before (prefs on: open the panes when needed; pref off: don't open the panes when needed), but there's no UI for them.
We should, (sigh, again) repurpose them for the behavior you describe (prefs on: don't automatically hide the panes on startup; prefs off: hide the panes on startup).

Filed bug 804575.

> Moving the toggle and close buttons on the right may still make sense,
> though, but we can leave that for the toolbox refactoring.

Yeah.

Comment 5

[Victor Porof [:vporof][:vp]]

https://hg.mozilla.org/integration/fx-team/rev/ff163b446688

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/ff163b446688