1913209 - Ctrl + Shift + Z redo shortcut is hijacked by the debugger unless the Override Keyboard Shortcuts site permission is allowed

Status: NEW

(DevTools :: Debugger, defect, P3)

Description

[Forest]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0

Steps to reproduce:

1. Revoke a site's Override Keyboard Shortcuts permission in the Page Info: Permissions panel. (I did this because the site was stealing Firefox's built-in navigation and menu shortcuts, which is becoming more common lately. GitHub is one notable offender.)
2. Type some text in an input box on that site.
3. Edit the text.
4. Press Control + Z to undo the edit.
5. Press Control + Shift + Z to redo the edit.

Actual results:

The Firefox debugger panel opened.

Expected results:

The undone edit should have been redone. The debugger panel should not have opened.

This is very disruptive on linux, at least, where that redo shortcut is common on major desktop environments.

It also seems to be a clear bug in Firefox specifically, given that the official documentation lists Ctrl + Shift + Z as the redo shortcut:

https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly#w_editing

Discovered on Firefox 115.14.0esr

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'DevTools::Debugger' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Forest]

I intended this to be filed against product: Firefox (maybe component: Keyboard Navigation?) but the bot changed it, and it seems I cannot change it back. :( I hope this report doesn't get overlooked.

Comment 3

[Nicolas Chevobbe [:nchevobbe]]

(In reply to Forest from comment #2)

I intended this to be filed against product: Firefox (maybe component: Keyboard Navigation?) but the bot changed it, and it seems I cannot change it back. :( I hope this report doesn't get overlooked.

This looks like the right component to handle this issue, we'll have a look

Comment 4

[Julian Descottes [:jdescottes]]

Thanks for filing, at this point it's very challenging to redefine key shortcuts for DevTools panels, so maybe the best approach will be to move forward with Disabling devtools by default (Bug 1704519) unless they have been opened a first time.

In the meantime, if you want to FULLY disable devtools, you can set devtools.policy.disabled to true, and it will avoid opening devtools.

Comment 5

[Forest]

so maybe the best approach will be to move forward with Disabling devtools by default (Bug 1704519)

That bug mentions a checkbox in the DevTools settings to disable the shortcut. The only one I found is "use the F12 key to open or close DevTools", which doesn't help with this problem. Are you referring to a different setting?

In the meantime, if you want to FULLY disable devtools,

I use dev tools somewhat often, so fully disabling them wouldn't really be helpful.

Comment 6

[Julian Descottes [:jdescottes]]

(In reply to Forest from comment #5)

so maybe the best approach will be to move forward with Disabling devtools by default (Bug 1704519)

That bug mentions a checkbox in the DevTools settings to disable the shortcut. The only one I found is "use the F12 key to open or close DevTools", which doesn't help with this problem. Are you referring to a different setting?

No at the moment it's just about F12, because that was the main source of complaints, but as you filed here, stealing ctrl shift Z is really not great, so we could also disable the panel shortcuts for new users. Although, as you mentioned you are actually using devtools from time to time, so that wouldn't actually help in your case. I still think it's relevant to disable those key shortcut entry points for new profiles, but we need something else here.

Shortcuts are really complicated to modify, we always end up having a conflict with another existing OS or application shortcut...
I can think of another relatively short term option: add another preference/checkbox to disable tool shortcuts when devtools are not open (then they would still work to switch between tools, but no longer to open / close the toolbox).

Putting the bug back to triage to see if we can do something unrelated to the onboarding topic.

Comment 7

[Forest]

I can think of another relatively short term option: add another preference/checkbox to disable tool shortcuts when devtools are not open

That would be helpful. (At least as a workaround until the shortcut conflicts can be resolved or custom key binding can be developed.)

Comment 8

[Julian Descottes [:jdescottes]]

Suggestion from :nchevobbe could actually be a much better solution here: for the debugger shortcut, we should check if the event comes from an input/textarea etc... and avoid handling it in that case.