972662 - Expose DevTools key shortcuts in about:keyboard (and allow them to be customizable)

Status: NEW

(DevTools :: Framework, enhancement, P3)

Description

[Rob Campbell [:rc] (:robcee)]

Our (developer tools) shortcut keys occupy a lot of keyboard space. They may conflict with other addons. We should provide a means to customize these keys or disable them to better fit with other customizations.

Comment 1

[Samuel Bronson]

Preferably, you would create a general keymap framework that extensions can also use, which could be used even in, say, Thunderbird.  This would have a similar motivation to the customizable toolbars we already have, though in implementation it would more resemble Emacs or even Visual Studio.

An extension would be able to register any number of commands, each of which would have, say:

 * An identifying name (possibly qualified by the extension UUID?) for use in the actual preferences

 * Maybe some kind of localizable name?

 * Default key bindings [anywhere from none to several].
   (This might be OS-dependent, even beyond the usual Ctrl/Option substitution.)

 * Either a docstring (which would describe the command in more detail)
   or at least links to online help.

There would probably also have to be some kind of "key binding manager" that would let the user configure all of this.

Comment 2

[RDL]

Meantime, there is a very popular extension, Keyconfig, which does this. However, it is unsigned and likely to remain so. Perhaps you could help us all by forking it and getting it signed on AMO, thus ensuring its continued availability.

That would ensure that those of us who wish to use localised (en-GB in my case) 'Release' versions would not instead have to resort to the mooted 'Unbranded' version which would only be available in en-US.

Any chance?

Comment 3

[RDL]

Sorry - I forgot to paste the reference:

keyconfig 20110522 • mozillaZine Forums

http://forums.mozillazine.org/viewtopic.php?f=48&t=72994

Comment 6

[08xjcec48]

Please update this bug's categories to:

Product: Firefox
Component: Keyboard Navigation
Platform: Desktop  All

Please also mark #1267145 as a duplicate of this bug.

Comment 7

[Sebastian Zartner [:sebo]]

As this one focuses on customization of the DevTools shortcuts, maybe it would make sense to mark this bug as a duplicate of a more general one instead of the other way round.

Sebastian

Comment 8

[Hani Yacoub, Desktop QA]

Keeping the bug as it is for now until we might receive more information from the other needinfo request.
Thanks.

Comment 9

[08xjcec48]

After you decide what issue to keep, please add this link to its "see also" field: https://connect.mozilla.org/t5/ideas/customizable-hotkeys/idi-p/4979

Comment 10

[Sebastian Zartner [:sebo]]

(In reply to André from comment #9)

After you decide what issue to keep, please add this link to its "see also" field: https://connect.mozilla.org/t5/ideas/customizable-hotkeys/idi-p/4979

I've referenced it in bug 1635774.

(In reply to Sebastian Zartner [:sebo] from comment #7)

As this one focuses on customization of the DevTools shortcuts, maybe it would make sense to mark this bug as a duplicate of a more general one instead of the other way round.

Actually, I agree with Hani that the bugs should be kept separate, at least for the time being.
As written in the bug above, a general way to customize shortcuts should also cover the ones of the DevTools. Though the DevTools may also provide a separate way to adjust them in the meantime.

One way this could be implemented would be via a "Custom..." option in the Keybindings drop down. That option could then open a dialog allowing to manage all the different keybindings used within the DevTools.

Sebastian

Comment 11

[Alexandre Poirot [:ochameau]]

It sounds counter productive to re-invent about:keyboard within DevTools, so let's try to aim at exposing DevTools key shortcuts in it so that users can see all of them in one place and allow them to be modified by the user.

Comment 14

[Alexandre Poirot [:ochameau]]

James, What about exposing all DevTools keyboard shortcuts to about:keyboard?

There is some implementation investigation to do on our side, but I'd like to discuss with you about the usability challenge of dropping so many shortcuts in this UI. This would immediately outnumber DevTools shortcuts versus all exiting Firefox shortcuts.

See the list of existing devtools shortcuts over there:
https://firefox-source-docs.mozilla.org/devtools-user/keyboard_shortcuts/index.html
(which may not even be exaustive, nor correctly maintained)

Comment 15

[Alexandre Poirot [:ochameau]]

(If we extends the availability of panel-specific keyshortcuts to be firefox-global instead of panel-only we are going to address bug 861815, bug 1567550, bug 1746583, bug 1780446)

Comment 16

[Joe Smith]

Hi,
Why is this 12 year accessibility issue not resolve ?
What does Mozilla Foundation's 500 million a year go to if not firefox's basic accessibility function ?

Check out these threads about it, they are full of good ideas

https://connect.mozilla.org/t5/ideas/customizable-hotkeys/idi-p/4979

https://connect.mozilla.org/t5/discussions/hotkeys-yes-please/m-p/115957

https://connect.mozilla.org/t5/discussions/customizable-hotkeys-is-live-please-help-us-scope-version-2/m-p/129670

Comment 17

[James Teh [:Jamie]]

(In reply to Alexandre Poirot [:ochameau] from comment #14)

James, What about exposing all DevTools keyboard shortcuts to about:keyboard?

I believe you filed bug 2000889 and bug 2001074 for that. :) Should we mark bug 2000889 at least as a duplicate of this bug 972662?

I'd like to discuss with you about the usability challenge of dropping so many shortcuts in this UI. This would immediately outnumber DevTools shortcuts versus all exiting Firefox shortcuts.

I'm not too concerned about that after bug 2041506, which has now landed. Categories are now collapsible and collapsed by default, so Dev Tools shortcuts won't overwhelm the UI unless a user explicitly chooses to expand that category.

(In reply to Alexandre Poirot [:ochameau] from comment #15)

(If we extends the availability of panel-specific keyshortcuts to be firefox-global instead of panel-only we are going to address

about:keyboard can't currently support non-global shortcuts. On the other hand, it seems really problematic to make all of the panel-specific shortcuts global:

1. I don't really understand why users would want that: it means they have to consume shortcuts globally that will generally only be used when the panel is open.
2. Because those shortcuts have bindings by default, that would mean that Dev Tools consumes even more space in the default key map than it already does, which is IMO already more than it should.
3. Some of the bugs you referenced seem to be suggesting we want the opposite: that some shortcuts shouldn't work from inside other tools.

Comment 18

[Sebastian Zartner [:sebo]]

(In reply to James Teh [:Jamie] from comment #17)

(In reply to Alexandre Poirot [:ochameau] from comment #15)

(If we extends the availability of panel-specific keyshortcuts to be firefox-global instead of panel-only we are going to address

about:keyboard can't currently support non-global shortcuts. On the other hand, it seems really problematic to make all of the panel-specific shortcuts global:

I agree with James here. Making devtools-specific or even panel-specific shortcuts globally available also causes many conflicts. E.g. Ctrl+F is used for searching within the page, but inside the DevTools it lets you search within the related panel. F11 in the page toggles fullscreen mode while inside the Debugger it steps into the next function call.

So I'd argue this requires introducing contextual mappings like some IDEs like VS Code provide them. In contrast to those IDEs, those contexts can be static, though, which should reduce the implementation complexity quite a bit.

Therefore, I'd say, the first step is to add contextual logic to the shortcut management functionality. And based on that, move the specific DevTools shortcuts step by step to this new mechanism.

All globally registered shortcuts for the DevTools can, of course, already be moved about:keyboard.

Sebastian

Comment 19

[James Teh [:Jamie]]

(In reply to Sebastian Zartner [:sebo] from comment #18)

So I'd argue this requires introducing contextual mappings like some IDEs like VS Code provide them. In contrast to those IDEs, those contexts can be static, though, which should reduce the implementation complexity quite a bit.

It's still very tricky to come up with a good UI for that, though, especially if you want to flag conflicts to the user. Do you flag conflicts with global commands, only conflicts within the current context, etc.? Are there separate contexts that can apply simultaneously; e.g. Dev Tools as a whole vs specific Dev Tools panels? And how do you manage conflict reporting in that case?

Therefore, I'd say, the first step is to add contextual logic to the shortcut management functionality.

FWIW, this is a pretty big lift and it's not something the accessibility team has the capacity to do right now, so this is unlikely to happen any time soon.

All globally registered shortcuts for the DevTools can, of course, already be moved about:keyboard.

Happy to try to help now if there are missing global shortcuts, though.

Comment 20

[Sebastian Zartner [:sebo]]

(In reply to James Teh [:Jamie] from comment #19)

(In reply to Sebastian Zartner [:sebo] from comment #18)

So I'd argue this requires introducing contextual mappings like some IDEs like VS Code provide them. In contrast to those IDEs, those contexts can be static, though, which should reduce the implementation complexity quite a bit.

It's still very tricky to come up with a good UI for that, though, especially if you want to flag conflicts to the user. Do you flag conflicts with global commands, only conflicts within the current context, etc.? Are there separate contexts that can apply simultaneously; e.g. Dev Tools as a whole vs specific Dev Tools panels? And how do you manage conflict reporting in that case?

Good point! I'd say, if they don't share the same context, this is not a big deal for an initial implementation, as it's not a hard conflict, i.e. it depends on whether the DevTools are focused, and we already have those conflicts right now without exposing them to the users. But yes, ideally, those conflicts should be exposed as well.
It does get more complicated when they share the same context, though. And yes, devtools-wide vs. panel-specific is a good example for that. So when the shortcuts are both devtools-wide or one is devtools-wide and the other one panel-specific, those conflicts have to be exposed to the user.

Currently, there is an alert shown in case of a conflict, which I think can be reused for that case.

The UI about conflict handling could be improved in a separate bug (or several).
Generally, the conflict message on hard conflicts could be improved explaining that the existing assignment will be removed when applying the new one, so it's clear that there can only be one assignment for a specific shortcut. (This could already happen independently of this bug.)
For soft conflicts, this should only be a note and the existing assignment would be kept when applying the new shortcut.

A good example for all that are the shortcuts for changing the zoom (i.e. Ctrl/Cmd++, Ctrl/Cmd+-, and Ctrl/Cmd+0). Those work in the global context as well as the devtools context but are independent from each other, meaning when the page is focused, they zoom the page, when the DevTools are focused, they zoom the DevTools. So they can be applied in both contexts, i.e. it is a soft conflict. Though when you try to assign one of those shortcuts to a devtools-panel-specific action, let's say searching for files by name in the Debugger (Ctrl/Cmd+P), that's a hard conflict, meaning the shortcut for chaning the zoom will be unassigned when applying the shortcut.

Therefore, I'd say, the first step is to add contextual logic to the shortcut management functionality.

FWIW, this is a pretty big lift and it's not something the accessibility team has the capacity to do right now, so this is unlikely to happen any time soon.

I assume, the logic wouldn't be too complicated given the aforementioned three contexts, global, devtools-wide, and devtools-panel-specific. In my understanding (not having read the underlying code), this mainly requires three things: introducing the contexts themselves, extending the logic for hard conflicts by one that also recognizes soft conflicts (depending on the relation between the contexts), and exposing soft conflicts in the UI.
Though I get that these changes are not trivial and require resources.

All globally registered shortcuts for the DevTools can, of course, already be moved about:keyboard.

Happy to try to help now if there are missing global shortcuts, though.

Actually, the list under "Browser Tools" seems pretty complete to me. I currently don't see any missing shortcuts, but I'll file a bug if there is something missing.

Sebastian

Comment 21

[Joe Smith]

Even though they're understood to be dev tools, they are integral of the final firefox package.

They are not just leftover debug systems. They are actually of use to advanced users. I occasionally use them for non-dev things.

I think for all base-package keyboard, mouse (joystick, gesture, gaze tracking etc.. etc. ) mapping between user inputs and actions, should all be part of a single framework.

Yes there is a global mapping and context specific mapping, but games, which have some of the most sophisticated input to action mapping of any software, also have a concept of global versus context specific action mapping and they should be used as inspiration for the new system.

And add-on action maps, should register their inputs/action/context as a page in about:keyboard as well (in addition to a copy in their own addon management page).

QMK keymap layout system is probably another good place to look for how to handle changing keybinding layouts on the fly based on context.

I imagine in the future it will be expected of processes that they should externally communicate their current input context to action remapper software (like, xmbc, ymbc, powertoys keyboard manager and AltSnap which are currently only context aware for the name of the current process but not its state )

Comment 23

[Alexandre Poirot [:ochameau]]

(In reply to James Teh [:Jamie] from comment #17)

I believe you filed bug 2000889 and bug 2001074 for that. :) Should we mark bug 2000889 at least as a duplicate of this bug 972662?

OH sorry about that, I cleaned up these bugs...

I'm not too concerned about that after bug 2041506, which has now landed. Categories are now collapsible and collapsed by default, so Dev Tools shortcuts won't overwhelm the UI unless a user explicitly chooses to expand that category.

Oh that looks very nice, I missed this improvement!
It will certainly help not overwhelm people not caring about DevTools, but it may not be enough for Web Developers.
We may need nested categories or something along these lines.
Something to still be able to group DevTools key shortcuts per panel or context, like our existing documentation page.
Any opinion on this?

(In reply to Alexandre Poirot [:ochameau] from comment #15)

(If we extends the availability of panel-specific keyshortcuts to be firefox-global instead of panel-only we are going to address

about:keyboard can't currently support non-global shortcuts. On the other hand, it seems really problematic to make all of the panel-specific shortcuts global:

1. I don't really understand why users would want that: it means they have to consume shortcuts globally that will generally only be used when the panel is open.
2. Because those shortcuts have bindings by default, that would mean that Dev Tools consumes even more space in the default key map than it already does, which is IMO already more than it should.
3. Some of the bugs you referenced seem to be suggesting we want the opposite: that some shortcuts shouldn't work from inside other tools.

Oh I briefly mentioned these bugs for tracking purpose.
My only request was about UI. There is much more analysis to be done as to how to actually implement the shortcuts through about:keyboard. Part of this is how to do have all shortcuts be global.

1. I do not intent to migrate all devtools shortcuts to become global. Only some, which are known to be very problematic like debugger stepping being easily not functional depending on your current focusing state. Not global as always enabled, but not only listened at the devtools iframe level. This would have been done independently of migrating to about:keyboard, but I mentioned the related bugs as it may make this trivial.

2. There is an opportunity to move from devtools-panel-specific to become devtools-specific (but still not global at all). Same, forcing us to revising keypress listener will ease revising this.

3. The vast majority of key shortcuts would stay only functional if, and only if, devtools are opened and probably focused. (to be clarified through extending analysis. I don't expect us to do that through bugzilla comments)

All that to say, we will take care of implementing proper event listener logic as we start submitting patches. We may as well start with keeping the exact same behavior as today.
My first blocker was only about:keyboard UI, where we need coordination with you and the rest of Firefox frontend shortcuts. There was no point in considering starting working on this if the UI is a no-go to start with (which is was like 3 days ago, before bug 2041506 ;))

Comment 24

[James Teh [:Jamie]]

(In reply to Sebastian Zartner [:sebo] from comment #18)

I assume, the logic wouldn't be too complicated given the aforementioned three contexts, global, devtools-wide, and devtools-panel-specific. In my understanding (not having read the underlying code), this mainly requires three things: introducing the contexts themselves

If we're having soft vs hard conflicts, we also need to have some abstraction to define dependencies between contexts.

(In reply to Alexandre Poirot [:ochameau] from comment #23)

We may need nested categories or something along these lines.
Something to still be able to group DevTools key shortcuts per panel or context, like our existing documentation page.
Any opinion on this?

Nested categories seems like it would need UX design and we unfortunately don't have any UX resources allocated to this project any more. I guess we could just have several categories for Dev Tools - "Dev Tools Console", "Dev Tools Inspector", etc. - but I guess whether that works well depends on how many categories we'd need.

My first blocker was only about:keyboard UI, where we need coordination with you and the rest of Firefox frontend shortcuts. There was no point in considering starting working on this if the UI is a no-go to start with (which is was like 3 days ago, before bug 2041506 ;))

Fair. FWIW, we don't have any capacity allocated to this beyond Firefox 154; i.e. bug 2041506 and a few small bug fixes. Whether we can get any product/UX/front-end resources allocated to this beyond that point is not a question I can answer.