Notes from story time:

• Ctrl + + is the browser's zoom feature. Ctrl + W closes the browser tab. Let's go with these for the moment but make sure they are easy to change in the code.
• Possibly solution (@ECohen_WMDE): Making all of them Ctrl + Shift + … would probably solve the issue, but also make everything a bit harder to use.
• How is this supposed to work on MacOS?

Change 722831 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):

[mediawiki/extensions/VisualEditor@master] Implement basic Ctrl+Shift+Up/Down/Del support in new sidebar

https://gerrit.wikimedia.org/r/722831

I looked into possible implementation details.

1. Some of the shortcuts are meant to be local, only when the focus is on a very specific element. Therefor a local event handler seems to be the way to go. See https://gerrit.wikimedia.org/r/722831.
2. Some are more global (at least global within the template dialog). I'm not exactly sure how to proceed here.
   • Some code simply uses accesskey="…" attributes. There is a nice OO.ui.mixin.AccessKeyedElement in OOUI we can use to do this.
   • ve.ui.CommandHelpDialog is the dialog that lists all shortcuts that are available in VE. But this is not an entry point, only a consumer.
   • Search the code for ve.ui.commandHelpRegistry.register(). This looks like the way to make shortcuts visible on the help screen. But it probably doesn't activate the shortcut.
   • Search the code for ve.ui.triggerRegistry.register() to find the actual keyboard shortcuts.
   • There is a method to .unregister() all of this again. I'm not sure if this is necessary. Maybe it's possible to register the shortcuts in a way so they are only active in the dialog. Or simply not have any code that reacts on the actions, except the dialog is currently active.

Change 722831 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Implement basic Ctrl+Shift+Up/Down/Del support in new sidebar

https://gerrit.wikimedia.org/r/722831

Change 724040 had a related patch set uploaded (by Awight; author: Awight):

[mediawiki/extensions/VisualEditor@master] [WIP] Keyboard shortcut to add a new template

https://gerrit.wikimedia.org/r/724040

Skip the nice to have for the new sprint

Change 724953 had a related patch set uploaded (by WMDE-Fisch; author: WMDE-Fisch):

[mediawiki/extensions/VisualEditor@master] [WIP] Template dialog access keys using VE commands

https://gerrit.wikimedia.org/r/724953

Change 724040 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Keyboard shortcut to add a new template

https://gerrit.wikimedia.org/r/724040

Change 725312 had a related patch set uploaded (by WMDE-Fisch; author: WMDE-Fisch):

[mediawiki/extensions/VisualEditor@master] Add more keyboard shortcuts for VE template dialog

https://gerrit.wikimedia.org/r/725312

The particular hotkeys we've chosen conflict with others on my system, we should determine who else will have these conflicts. In my case, I get:

(1) <control>-<shift>-U never works for me, instead I insert an underlined "U" in a text input:

(2) <control>-<shift>-Y sometimes pops up the Firefox downloads window. Only after clicking on a parameter in the sidebar, and triggering another bug which prevents the content input from being focused by the sidebar click.

Change 725312 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Add more keyboard shortcuts for VE template dialog

https://gerrit.wikimedia.org/r/725312

(1) <control>-<shift>-U never works for me, instead I insert an underlined "U" in a text input:

CTRL-U is an VE shortcut for underline. So I guess that's the conflict here. How about CTRL-SHIFT-N?

@ECohen_WMDE

In T290262#7401621, @WMDE-Fisch wrote:

CTRL-U is an VE shortcut for underline.

I don't know about this, because * ctrl-u opens the source window, * happens outside of VE, and * once in this strange underlining mode, only hex characters are accepted. I think it's a unicode input thing, if you type "u123<enter>" your input turns into "ģ".

Oh no - I did a bunch of research to try to find unused keys (browsers use almost all of them before you even start looking at the VE shortcuts) but it seems like I wasn't able to. Where is this ticket at at the moment? The boxes are checked in the task description but do we need to find different key combinations?

In T290262#7405409, @ECohen_WMDE wrote:

The boxes are checked in the task description but do we need to find different key combinations?

I've merged the patches because they will enable the originally planned hotkeys for some number of users. Only people with debian and ubuntu are affected by these particular collisions, AFAIK.

Change 727342 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):

[mediawiki/extensions/VisualEditor@master] Fix sidebar bottom position when pressing Ctrl+Shift+E

https://gerrit.wikimedia.org/r/727342

Change 727342 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Fix sidebar bottom position when pressing Ctrl+Shift+E

https://gerrit.wikimedia.org/r/727342

@awight @WMDE-Fisch - can you clarify what the open question is here?

In T290262#7436657, @ECohen_WMDE wrote:

@awight @WMDE-Fisch - can you clarify what the open question is here?

It seems, that we can not use Ctrl+Shift+U because it conflicts with key combinations on Linux/Debian/Ubuntu systems and need another combination for that. There also seems to be minor issues with Ctrl+Shift+Y but as I understood @awight this is only in some edge cases and we might be fine there (?).

Ok makes sense - do you know of any key combinations that are available? The ones I chose don't have any specific meaning, they just seemed to be the few not already used by browsers and VE based on the research I did. Not sure where else to check?

In T290262#7436996, @ECohen_WMDE wrote:

Ok makes sense - do you know of any key combinations that are available? The ones I chose don't have any specific meaning, they just seemed to be the few not already used by browsers and VE based on the research I did. Not sure where else to check?

Good question. I failed finding a good source to check that in general. I played around on my system though and it seems, that Ctrl+Shift+I might be working fine and does not block anything important. You could check as well with how this is on macOS and your browser. It might do something, but if it's nothing that you would consider essentially important, than we can just 'hijack' the combination for the case that the template dialog is opened.

Note that both Ctrl + Shift + E as well as Ctrl + Shift + U are only a problem as long as the cursor is in a text field, e.g. in the parameter search field. That's because they are both meant to enter characters:

• Ctrl + Shift + E is for "Emoji". You can, for example, type "up" and press enter to get 👆.
• Ctrl + Shift + U is for "Unicode". You have to type the character's hex number, e.g. "261d" and enter to get ☝.

When you press tab to leave the text field both key combinations loose this crazy Unicode behavior and start doing what we want them to do.

I tried a few things to suppress this Unicode behavior, but it appears like this is impossible from JavaScript. The best idea I have for a hack is to unfocus any text field the moment Ctrl + Shift is pressed. But what if a user want's to enter a Unicode character?

Ctrl + Shift + I is for the developer tools in the browser. I would not hijack this if we can avoid it.

I checked https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts for Ctrl + Shift + keyboard combinations, looked at those already added by VE and manually tested in Firefox, Chrome and Edge:

I only found Ctrl + Shift + X and Y that seem to be not taken by anyone yet ^^'. D also seems to be relatively free, only Firefox is using it as a short cut to create a new bookmark folder. I guess it wont hurt much if that specific combination does not work when you're currently on a template dialog.

So we're already using Y maybe we should go for X and D to cover for E and U.

Thanks for the research and explanations @WMDE-Fisch @thiemowmde - if X and D have less conflicts, less go for it! I tried them both out and X did nothing but D seems to be a shortcut to bookmark all open tabs in chrome. Still, this seems like a less problematic override though than the unicode behavior?

I also think think it's pretty important that the shortcuts can be used even when in text field. Seems like switching the letters would let us do this most easily (and allow people to use unicode if they like). Should we update the task description then?

Change 732264 had a related patch set uploaded (by WMDE-Fisch; author: WMDE-Fisch):

[mediawiki/extensions/VisualEditor@master] Change template dialog hotkeys

https://gerrit.wikimedia.org/r/732264

Change 732264 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Change template dialog hotkeys

https://gerrit.wikimedia.org/r/732264

Nice to haves not implemented.

Just tested them out! They are all working for me (very exciting) except unfortunately for Ctrl+Del (using Cmmd since I'm on a mac). Could the problem have to do with mac doing shortcuts differently somehow?

Follow-up ticket(s) to create, as discussed in today's demo time:

• T294519
  • Ctrl + Del not working on Mac.
• T294521
  • Ctrl + Shift + X conflicts with a shortcut already in use in VE.
  • Add the shortcuts to the VE help screen.
  • Make sure screenreader users get the shortcuts explained when they are in the dialog. (This might already be part of T289653.)

Make sure screenreader users get the shortcuts explained when they are in the dialog. (This might already be part of T289653.)

Yes, this partially done here: T291284: Each sidebar element should have a clear label, role, state and description/instructions though it doesn't include when the toolbar buttons themselves are in focus. Agree this could be part of follow-up work.

Change 724953 abandoned by WMDE-Fisch:

[mediawiki/extensions/VisualEditor@master] [WIP] Template dialog access keys using VE commands

Reason:

Not needed anymore

https://gerrit.wikimedia.org/r/724953