Prevent accidental quick menu shortcuts from triggering dialogs

[digitarald]

Quick Open and Command Menu are highly ranked feature requests, but will take a few quarters to get scoped, implemented and shipped. Meanwhile, thanks to muscle memory, the lag of those shortcuts triggers intrusive Firefox features that interrupt the developers workflow.

Quick Open/File Finder Command/Control+P – 😤 Only works in Debugger, otherwise Firefox triggers print dialog Command Menu/Palette Command/Control+Shift+P – 😤 Firefox triggers private window

Used in Atom, VSCode, Sublime and Chrome (IntelliJ/WebStorm provides an action menu via ⇧⌘A)

Possible Solutions

One simple short-term fix would be to capture these shortcuts as no-op when DevTools are focused, so they don't trigger the default behavior. The features could still be triggered by shortcut when other parts of Firefox are focused.

Risk: For users expecting it to do quickopen/commandmenu, they will go from "this shortcut does X" to "this shortcut does nothing", possibly leaving them with the feeling something is broken.

If we want to make this even nicer, we can log a friendly message to the console that we have those features planned in the future. Telemetry could track how many users hit the intervention.

Thoughts?

cc @martinbalfanz @violasong @captainbrosset @janodvarko @jasonLaster

[juliandescottes]

I am not sure the short term workaround improves the situation.

For users expecting it to do quickopen/commandmenu, they will go from "this shortcut does X" to "this shortcut does nothing", possibly leaving them with the feeling something is broken.

For users actually using PrintDialog/PrivateWindow shortcuts and using DevTools, we now risk swallowing their events if they focused DevTools by "mistake". I don't think a console.log is enough feedback here.

[digitarald]

For users expecting it to do quickopen/commandmenu, they will go from "this shortcut does X" to "this shortcut does nothing", possibly leaving them with the feeling something is broken.

Added as risk, should have called that out of course. My hypothesis is that the impact of unexpected-dialog/window is worse than the impact of nothing-happening and intentional-print/private-window-not-happening.

It is hard to test easily. I would guess we see a lot print dialogs for devtools users, but print dialog isn't Telemetry instrumented. Surveys could help in how many users are running into this.

[juliandescottes]

It is hard to test easily. I would guess we see a lot print dialogs for devtools users, but print dialog isn't Telemetry instrumented. Surveys could help in how many users are running into this.

I think we can easily instrument Ctrl/Cmd + P from DevTools (without blocking the event or anything) and gather data then!

[fvsch]

The risks described by Julian seem real, while the benefits of blocking those shortcuts seem a bit theoretical. We have feedback from users who want a Command Palette like in Chrome/VSCode/etc., but do we have feedback specifically about the shortcuts? Do people trigger Print dialog or a new Private Browsing window by mistake repeatedly, or just once or twice?

Personally I'm always triggering the Print dialog and it's driving me nuts, but it happens because I'm trying to use "Go to file" in VS Code and the focus was still on Firefox. But even if DevTools blocked this shortcut, that would only prevent that issue for me like 20% of the time maybe? (Other times: focus is on another part of Firefox, like the tab strip or navbar, or in page content.)

Another proposal: on Cmd+P in DevTools (with the focus on the toolbox or in any panel), switch to the Debugger and show its "Go to file" dialog. (For now I would leave Cmd+Shift+P alone).

• Better: offer some value for users
• Better: for users who actually wanted the Print dialog or a Private Browsing window, we reduce frustration by showing something instead of blocking silently
• Riskier: we only have JS sources, while Chrome has JS + CSS + images

[digitarald]

Another proposal: on Cmd+P in DevTools (with the focus on the toolbox or in any panel), switch to the Debugger and show its "Go to file" dialog. (For now I would leave Cmd+Shift+P alone).

I thought about that one as well since filing the issue, it makes a lot of sense for Cmd-P! When it can be done with little effort we should prioritize it. Filed as bug 1567550.

[digitarald]

For reference https://twitter.com/FirefoxDevTools/status/1152265834070339584 (probably no too many responses, as I posted on a Friday – will re-post on Monday again)

[juliandescottes]

If we want to gather some data on the usage of the shortcuts I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1567497 and there's a patch ready. But given the last comments I'm not sure if you want to do that or do some implementation already?

[digitarald]

@juliandescottes the probe would only tell one part of the story, but lets get it in now to get some initial idea. The full story would only count cases where dialogs or windows were opened and closed without interaction (which is a lot more costly to instrument than this problem allows us to invest). We'll only know a bit more after we got this landed and uplifted to beta.

[digitarald]

Command menu is on the horizon, so this can be closed.