1300934 - Provide an option to ignore debugger statements when the debugger panel is not active.

Status: RESOLVED DUPLICATE of bug 1578220

(DevTools :: Debugger, enhancement, P3)

Description

[Tim Nguyen :ntim]

STR:
- Go to https://www.avito.ru/
- Press Ctrl+Shift+C

AR:
- mouse selection gets interrupted by debugger which pauses

ER:
- should not get interrupted (or there should be a way to disable that behaviour/the debugger)

Comment 1

[Tim Nguyen :ntim]

Chrome and Safari support both mouse selection and pausing the debugger at the same time.

Possible solutions:
- Supporting both at the same time
- Simply not pause if we're inspecting an element
- Add a way to disable debugger
- Add a way to disable pausing

Comment 2

[Patrick Brosset <:pbro>]

See bug 1177346 about supporting mouse selection while paused at a breakpoint.

Comment 3

[Eddy Bruel [:ejpbruel]]

(In reply to Patrick Brosset <:pbro> from comment #2)
> See bug 1177346 about supporting mouse selection while paused at a
> breakpoint.

I doubt we're ever going to implement bug 1177346, due to how horrible nested event loops are in general.

Perhaps a reasonable alternative would be to provide users with an option to ignore debugger statements, even if the devtools panel is open? Patrick, what do you think?

Comment 4

[Patrick Brosset <:pbro>]

Providing users with an option for this seems a bit odd to me. I think people just assume that this works, and wouldn't really look for an option to change this behavior anyway. Also I wouldn't know where to put it in a place that they'd expect, and how to phrase it in a way to makes sense to them.

So if we're never going to be able to fix this properly, then we should avoid the situation altogether, and make it very obvious to users that we do:
- disable the debugger when the picker mode starts (i.e. the user clicks on the "element selection" button),
- re-enable it when the picker mode stops (i.e. the user has selected a node),
- display a warning banner that explains we can't pause while doing this.

We do have a banner already when you do this:
- go to the debugger
- pause execution
- go to the inspector

Comment 5

[Julian Descottes [:jdescottes]]

I think providing a way to disable debugger statements would be useful for the debugger, regardless of this particular issue. I remember Firebug implementing something like this, and used it while debugging pages where I had been too optimistic when adding "debugger" statements everywhere (see http://www.softwareishard.com/blog/planet-mozilla/firebug-tip-disable-debugger-keyword/ )

In the use case described in comment #1, the user is automatically brought to the debugger panel, so there's no need to put this information in the inspector.

Comment 6

[Patrick Brosset <:pbro>]

(In reply to Julian Descottes [:jdescottes] from comment #5)
> I think providing a way to disable debugger statements would be useful for
> the debugger, regardless of this particular issue. I remember Firebug
> implementing something like this, and used it while debugging pages where I
> had been too optimistic when adding "debugger" statements everywhere (see
> http://www.softwareishard.com/blog/planet-mozilla/firebug-tip-disable-
> debugger-keyword/ )
I see. This option does seem useful then.

But I still think, assuming we can't fix this properly [1], that we should just disable the debugger as soon as you start the element picker.

[1] which would mean being able to fully use the picker while paused.

Comment 7

[Eddy Bruel [:ejpbruel]]

Just had a discussion about this bug on irc. The consensus was that we should provide users with an option to ignore debugger statements when the debugger panel is not active.

Comment 8

[Sebastian Zartner [:sebo]]

Firebug allowed to ignore those statements by setting a disabled breakpoint on them. There might have been a better UI for this, though.

One idea I came up with years ago[1] was to display debugger statements as breakpoints within the Breakpoints side panel.
I.e. every debugger keyword would have a corresponding entry in the side panel, which allows to disable it.

This allows to disable the debugger keywords individually and all at once via the context menu of the side panel like for normal breakpoints.
Additionally to that there may still be an option for generally ignoring all debugger statements.

Eddy, Patrick, what do you think about the possibility to disable them individually? Should this be filed separately?

Sebastian

[1] https://github.com/firebug/firebug/issues/2923#issuecomment-103408235

Comment 9

[Patrick Brosset <:pbro>]

(In reply to Sebastian Zartner [:sebo] from comment #8)
> Eddy, Patrick, what do you think about the possibility to disable them
> individually? Should this be filed separately?
I like this idea, this sounds useful. This should be filed separately, and at https://github.com/devtools-html/debugger.html/issues

Comment 10

[Sebastian Zartner [:sebo]]

(In reply to Patrick Brosset <:pbro> from comment #9)
> (In reply to Sebastian Zartner [:sebo] from comment #8)
> > Eddy, Patrick, what do you think about the possibility to disable them
> > individually? Should this be filed separately?
> I like this idea, this sounds useful. This should be filed separately, and
> at https://github.com/devtools-html/debugger.html/issues

Good. Filed at https://github.com/devtools-html/debugger.html/issues/828.

Sebastian

Comment 11

[Szczepan Hołyszewski]

I vehemently disagree with downgrading the priority from P2 to P3 and type from defect to enhancement.

We absolutely DO NEED the option to disable the debugger statement altogether. The "disabled breakpoint" workaround is insufficient. Special handling of mouse selection is insufficient. NOTHING short of full direct absolute imperialistic fascist control over whether debugger statements are globally enabled or disabled will be sufficient.

There are websites that actively defeat devtools by repeatedly stopping on a debugger statement inside an eval(), which defeats the "disabled breakpoint" workaround because each of those debugger statements is distinct. Selecting elements with the mouse in the Inspector pane is NOT the only devtools functionality that this technique defeats. We NEED an ultimate weapon against this.

Comment 12

[Ryan Hendrickson [rhendric on GitLab, GitHub]]

I understand hiding the previous comment, but it does contribute a point that I think should be front and center in this bug, which is that there exist websites that are exploiting the debugger statement to effectively disable devtools, and there's no workaround for this yet. The two proposed alternative solutions—disabling individual debugger statements with breakpoints, and allowing element selection to work while the debugger is paused—would also not prevent this exploit. While this may not be a your-computer-is-pwned-class vulnerability, it is a case of a website taking control of an aspect of browser functionality that should be entirely under the user's control, and as such I think probably should be prioritized as a vulnerability of some sort. Or, at the very least, a defect rather than a request for enhancement.

Comment 13

[:Harald Kirschner :digitarald]

Thank you for the passionate points. The reason for marking this an enhancement is this is changing behavior and has to be evaluated.

Related, bug 1537609 shows an interesting analysis that required a JS engine patch to stop hitting debugger statements (and the side effects of nonsensical countermeasures.

The simple way would be a pref that switched off debugger statement handling in JS, while we evaluate the UX aspects for exposing this to developers. Giving more control over debugger statements, being able to turn them on and off, would make them much more powerful and bridge the gap between breakpoint- and statement-based pausing.

Comment 14

[Ryan Hendrickson [rhendric on GitLab, GitHub]]

IMO, a global pref would be an acceptable temporary workaround if it didn't require a browser restart to take effect. Having to restart the browser when I introduce debugger statements into my project of the day would be a big pain, as for almost all of my other web browsing, I would want debugger statements turned off.

For the ultimate solution, since I'm already offering my two cents, I would ideally like to see debugger statements handled as a per-host permission, with the same UX that Firefox uses for existing per-host permissions like web notifications and camera/microphone. I think it makes sense for debugger statements to be disabled by default; they have no benefit to the end user unless that user is a developer, in which case they are only useful on those sites that the developer is actively debugging, which will probably be a relatively small list of hosts like localhost and intranet-dev-server-4 and maybe qa.company.com. For those sites, Firefox should make it easy to enable the preference (‘Will you allow intranet-dev-server-4 to pause the debugger?’) and persist it; ideally, it's not something I'd have to toggle on and off manually whenever I start debugging for real versus inspecting a random website, and it also needn't be something that I have to dig for in layers of advanced devtools preferences.

Grouping this with privacy permissions also makes some sense because websites can exploit debugger statements to detect whether devtools is open, which could be seen as a privacy leak.

Comment 15

[Franklin?]

I have three more options.

First, when a lot of debugger statements are hit in quick succession, show an option to ignore further debugger statements from that page. This is similar to how browsers deal with pages with infinite alerts.

Second, ignore debugger statements in eval'd code, or have an option to ignore. The hint for the option could be shown after the page hits three debugger statements from eval'd code.

Third, make debugger statements turned off by default when you open dev tools. You must then turn them on in the debugger menu (using a very visible checkbox), every time you open them. That may be annoying, but considering it's a potential privacy leak, it's safer to have it off by default. Also, by forcing the option to be turned on manually, it builds a habit. There could be a dev tools preference to have it on automatically, for those who use a Firefox profile exclusively for debugging.

I saw this method of generating debugger statements in the wild:
function(){}.constructor("debugger")()

This method also works:
setInterval("debugger", 100)

Comment 16

[Szczepan Hołyszewski]

If adding a "pref that switches off debugger statement handling in JS" is "the simple way", and the only thing that blocks immediate implementation is the need to "evaluate the UX aspects of exposing it to developers", then I have wonderful news: those UX aspect have already been evaluated, and a solution has already been found - by Chromium. No UX disaster happened after they implemented it. Just copy their solution.

Comment 17

[Szczepan Hołyszewski]

"I would ideally like to see debugger statements handled as a per-host permission"

Sure, as long as that permission can be instantly toggled with one click on an UI element somewhere on the Sources panel. This is the desired UX with implementation precedent in at least one major browser, and nothing short of this will be sufficient.

Comment 18

[Jason Laster [:jlast]]

I'm confused, the "deactivate breakpoints" button in the sidebar disables debugger statements.

I would like to also be able to disable individual debugger statements. I think we could do this by providing a context menu option in the gutter and column breakpoints for "Never pause here", which is similar to chrome. On the server side, when a debugger statement is hit we will need to check if there is a breakpoint with a condition that evaluates to false at that location.

Comment 19

[Jason Laster [:jlast]]

Attachment: never pause.png

Comment 20

[:Harald Kirschner :digitarald]

Szczepan, just wanted to confirm, that Jason's post matched the feature you were requesting. The prior discussion in this bug was about disabling all handing of debugger statements without opening Debugger.

Comment 21

[Jason Laster [:jlast]]

Good point Harald, one thing we could easily do is have "deactivate breakpoints" work even if you dont open the debugger. I expected it would work, but was just surprised that the debugger had to open first.

Comment 22

[:Harald Kirschner :digitarald]

Related, the state of disabled debugging should be shown as potential "footgun" in the Debugger's toolbar icon: https://github.com/firefox-devtools/ux/issues/60

Comment 24

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

Redirect a needinfo that is pending on an inactive user to the triage owner.
:bomsy, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 26

[Alexandre Poirot [:ochameau]]

We are about to introduce a new settings in bug 1578220 to allow disabling debugger statements.