1568160 - Disable breakpoints should register on devtools open

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P2)

Description

[jackdesbwa]

Observed on 68.0.1 (64 bits) on Archlinux, but I remember it was present in older versions although I did not understand what happened before.

1. Deactivate debugger/exceptions (icon at the right in the step-in, next, step-out buttons bar)
2. Open a new tab with a page containing a bug, for example a one which opens a popup after a few seconds but did not check answer (blocked popup) before accessing it.
3. Before the bug happen, open the dev tools (I usually open network monitor Ctrl-Shift-E)

When the bug arises, the tab switches to debugger and stop the code on the error, despite debugger is disabled. (bad)
The debugger disabled symbol is present (good)
After hitting playing button, no further error is triggered (good)

As the debugger/exceptions are disabled, the debugger should ignore the event and do not stop execution, do not switch to debugger tab.

By the way, because of a confusing disabled symbol, I did not understand what happened before. I usually clicked on the symbol (switching debug enable status) and than behavior was even more confusing. A bit later, I thought I had to enable/disable to make it work as expected, and finally I realize that it seems to be only the first time (thus clicking on the button is not required to workaround) as if the disabled status is taken into account only when the tab has been opened.

Comment 1

[Jason Laster [:jlast]]

Hi, have you tried upgrading to the latest release. i believe this was fixed in the past couple of months.

Comment 2

[jackdesbwa]

Attachment: debugger_trig.html

As far as I can see, 68.0.1 is the latest stable release for Firefox on Linux right now.
I found another package [so that it is easy to do the test] named firefox-developer-edition which is in version 69.0b7 => same behavior.

To help to reproduce, I managed to get a minimal page that exhibit the problem, which is attached.

1. Disable debugger
2. Open the file in a new tab
3. Open network tab of dev tools Ctrl-Shift-E
4. Click on the page to emit debugger event

Expected: no debugger action
Observed: debugger tab is opened and execution is stopped
(same as before, with same correct behavior after hitting play)

Additional observations:

• If debug tab is opened instead of network tab, the bug is not present
• If debug tab was opened first than network tab is selected, the bug is not present

Comment 3

[Jason Laster [:jlast]]

Ahh, i see. If devtools is open, the debugger will pause and open the Debugger Panel. That is part of the spec. Sorry for the confusion.

Comment 4

[jackdesbwa]

I am not sure to understand you, or that you understood the subtle misbehavior I saw.
A behavior that is different depending on the path the tool is accessed sounds like a corner case, not a spec.

To help clarifying, I will expose the context in which I found it:
I like the debugger functionality when I do web development (even if I do few) but most of the time (regular navigation) it is useless for me. Thus, the "disable" button is almost always checked, except when I need it enabled.
However, I sometimes use inspector or network tabs on pages I do not maintain for various reasons. But several website have minor bugs that trigger the debugger despite my disablement. It is hugely annoying.

I have no idea how it works internally, but from an external point of view, it looks like:

1. a bug arises
2. the engine checks if dev-tools is opened [and probably if disabled, but this information is not up-to-date?]
3. switch to debugger tab / stop execution
4. load disabling state (too late)
   Next bugs (after hit of play button) do not open the tab again as expected.

The other way is (again external point of view):

1. debugger tab opened (by user), it loads disabling state (not too late)
2. user action: change tab
3. a bug arises
4. the engine checks disabled state and does nothing special (behavior expected)

Am I wrong to consider that something like "when a bug arises and the dev-tools is opened, switch to debugger tab ignoring the disable button state, unless the debug tab was previously opened" sounds like a really stupid spec thus is likely a bug?

Hope to have been more clear this time.

Comment 5

[jackdesbwa]

I just realized that I used the term tab for both browsing tabs and dev-tools panels which can be confusing.
It can be deduced from the context, but in last message "user action: change tab" does not have context at all; in this case, it is dev-tols panel.

Comment 6

[jackdesbwa]

Because of absence of answer, I reopened it in another ticket #1570892

Comment 8

[Jason Laster [:jlast]]

Thanks for clarifying jackdesbw. I see what you're saying now. It would be nice if the disable breakpoints button would work even if the debugger is not open.

Comment 9

[Jason Laster [:jlast]]

Attachment: Bug 1568160 - Disable breakpoints should register on devtools open. r=davidwalsh

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:jlast, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/35442c95e981
Disable breakpoints should register on devtools open. r=davidwalsh

Comment 12

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/35442c95e981