Open Bug 1300934 Opened 4 years ago Updated 2 months ago

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

Categories

(DevTools :: Debugger, enhancement, P3)

enhancement

Tracking

(Not tracked)

People

(Reporter: ntim, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

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)
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
See bug 1177346 about supporting mouse selection while paused at a breakpoint.
See Also: → 1177346
(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?
Flags: needinfo?(pbrosset)
Priority: -- → P2
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
Flags: needinfo?(pbrosset)
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.
(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.
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.
Summary: Don't pause debugger when inspector is in picker mode → Provide an option to ignore debugger statements when the debugger panel is not active.
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
Blocks: firebug-gaps
Flags: needinfo?(pbrosset)
Flags: needinfo?(ejpbruel)
(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
Flags: needinfo?(pbrosset)
(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
Flags: needinfo?(ejpbruel)
See Also: → 925269
No longer blocks: firebug-gaps
Product: Firefox → DevTools
Blocks: dbg-stepping
Priority: P2 → P3
Blocks: dbg-control
No longer blocks: dbg-stepping
Type: defect → enhancement

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.

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.

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.

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)

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.

"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.

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.

Attached image never pause.png

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.

Flags: needinfo?(rulatir)

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.

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

You need to log in before you can comment on or make changes to this bug.