1093776 - Select Debugger tab on user interested pauses (breakpoints, exceptions, etc)

Status: RESOLVED FIXED

(DevTools :: Debugger, defect)

Description

[Arthur Stolyar [:nekr]]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36

Steps to reproduce:

For now, when debugger hits breakpoint or paused on exception it only highlights Debugger tab.
I am a lot used Chrome DevTools and found it very useful, what when debugger pauses by some reason, debugger tab becomes selected. May be it's just my habit.

Anyway, would be good to disscuss that. But if that behavior is by design..

Comment 1

[Eddy Bruel [:ejpbruel]]

As far as I know, this was a conscious decision. It also becomes less obvious that selecting the debugger tab is the right thing to do once we get worker debugging. Should we select the debugger tab when any worker pauses? Just the selected worker? What if the main thread pauses when a worker is selected?

Personally, I'm not convinced that selecting the tab is an improvement over highlighting it, but if it's more consistent with chrome, we should at least consider it. I'm going to leave this bug open for a while to get other people's opinions on it.

Comment 2

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

I don't think it's always the case that the debugger is the right tool to observe a pause. For example, say I'm in the web console and I'm evaluating an expression that calls a function where I've put a breakpoint at (or a debugger statement). It has often been the case that I want to remain in the console and inspect some variables in the context of the paused frame.

I could perform the same inspection with the debugger using things like watch expressions, but many more people are familiar with inspecting using the console, than the debugger.

Comment 3

[Arthur Stolyar [:nekr]]

@past,

Not sure I am got your point. How it's possible to debug via console if script is paused? Or you mean something like this:

test(); // call fn with breakpoint
x; // get state of local var inside fn

If it is your case, I agree that this is useful, but only when you absolutely know what is going on in |test| fn. I understand what sometimes it's annoying that debugger tab is going to be selected again and again, but that is rarer case than when you need to select it, I think.

In most cases, anytime when exception occurs and debugger pauses, I always go to debugger tab. It's just first class action, if something happened in debugger what stops all the things -- need to inspect that in first place. Next, when debugging deeper -- yes, it's may be not so useful because you want to be in Inspector tab or in other.

I am not sure how that all should be for Workers, never had too much work with them.

Comment 4

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

(In reply to Arthur Stolyar [:nekr] from comment #3)
> Or you mean something like this:
> 
> test(); // call fn with breakpoint
> x; // get state of local var inside fn

Exactly.

> If it is your case, I agree that this is useful, but only when you
> absolutely know what is going on in |test| fn. I understand what sometimes
> it's annoying that debugger tab is going to be selected again and again, but
> that is rarer case than when you need to select it, I think.

You can't really make an informed argument about what is rare and what is common without data. Clearly you and I have opposite experiences, but we can't infer from that that the entire user population is split 50-50 on this.

Comment 5

[Arthur Stolyar [:nekr]]

> You can't really make an informed argument about what is rare and what is common without data.
> Clearly you and I have opposite experiences, but we can't infer from that that the entire
> user population is split 50-50 on this.

Yes, you are right. My argument is totally preconceived. Like your. Maybe it's ok to have an option in debugger about select/or not?

Comment 6

[Eddy Bruel [:ejpbruel]]

(In reply to Arthur Stolyar [:nekr] from comment #5)
> > You can't really make an informed argument about what is rare and what is common without data.
> > Clearly you and I have opposite experiences, but we can't infer from that that the entire
> > user population is split 50-50 on this.
> 
> Yes, you are right. My argument is totally preconceived. Like your. Maybe
> it's ok to have an option in debugger about select/or not?

I just had a talk with Panos on irc on how to deal with cases where there is no clear data on what most users want. We don't have a good way to get this data, so the default is to maintain the status quo.

Having said that, I don't want us to reject every proposal outright when we don't have the data, since that would amount to rejecting almost everything. After all, we didn't have the data when the original decision was made either.

What I'm going to do is bring your proposal up during the weekly team meeting on thursday, and let the team as a whole decide on it. In addition, I will ask our product guys for their opinion. Does that sound reasonable to you?

Comment 7

[Arthur Stolyar [:nekr]]

> Does that sound reasonable to you?

Yes, sounds good. I am also ok with just having option/flag for it. That way might satisfy both who wants this feature and who not.


Thanks for your answers :)

Comment 8

[Eddy Bruel [:ejpbruel]]

Have not been actively working on this for some time now. Unassigning myself so other people can have a shot.

Comment 9

[Jason Laster [:jlast]]

I believe this works now. Please let me know if you still see something.