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.

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.

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

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.

Debug statements should be handled as a per-host permission, with the same UX that Firefox uses for other per-host permissions like web alerts and camera/microphone, in the ideal world, if I may add my two cents to the discussion. Debugging statements should, in my opinion, be disabled by default since, unless a user is a developer, they are only relevant on the websites that the developer is actively debugging, which is likely to be a limited number of hosts like localhost, intranet-dev-server-4, and perhaps https://kokqa.com.