Problem/Motivation

Admin Toolbar Search (Alt + a) and the new Hide Toolbar feature (Alt + p) will both offer shortcuts in the next Admin Toolbar release, which is great. But shortcuts can sometimes conflict in the browser, depending on language, browser add-ons installed, etc.:

Alt+s (Option+s) happens to be a shortcut to type a Polish character of "ś". I imagine there are other languages with common problem. Can you suggest how to turn this off, please?

Proposed resolution

We could offer a predefined list of shortcuts in a drop-down, so that it can be defined by the user.

Admin Toolbar Search
For Admin Toolbar Search form, Alt + a could be the default (as it is currently) with for example these options as well?

Alt + a
Ctrl + Alt + s
Ctrl + Alt + a
Shift + Alt + a

Hide menu
The Hide menu feature could have these shortcut options:

Alt + p
Alt + h
Ctrl + Alt + p
Ctrl + Alt + h
Shift + Alt + p
Shift + Alt + h

Remaining tasks

Decide which shortcut options are useful to offer, weeding out the ones which are already taken in too many browsers.

Should the current checkbox ("enable") method remain? This is probably easiest, since it's the current method, as well as allow to check elsewhere if it's enabled or not, to check if JavaScript should be attached, should shortcut help text be shown, etc.

Alternatively, the checkbox could be removed, and turned into a drop-down, with Alt + a still being the default after install, but with "None" (i.e. no shortcut) as an option?

None
Alt + a
Ctrl + Alt + s
Ctrl + Alt + a
Shift + Alt + a

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Release notes snippet

CommentFileSizeAuthor
#10 Untitled document.jpg50.75 KBpaulocs

Comments

oknate created an issue. See original summary.

adriancid’s picture

I think is better to only change the shortcut to another different as we want to keep this module as plug and play, maybe a combination without letters?

oknate’s picture

I don't use the shortcut key. I think it's a great feature. I just don't use it. So I'm going to bow out and wait for people who use the feature to weigh in.

oknate’s picture

It could be that a patch to change the key allows those sites that want to change it to change it. If it could be that a settings file without a UI, a simple yml file.

skinio’s picture

It's very important to have an option to disable or change shortcut, becouse it override national letters shortcut and make unable to write content.
I was looking for solution and found this topic. For now if I want to write "ś" I need to open notepad, write it there, copy it and paste to drupal (insane). I love this module and don't want to remove it.

alison’s picture

Yes it would be really great to be configurable, if possible!

Another reason: "Alt + S" is the shortcut for the "History" menu in Firefox :)

alison’s picture

Also, there should be conspicuous documentation about the keyboard shortcut -- even if it doesn't become configurable. Ideally, this would be added as a tooltip if you hover over the field, but at a minimum, there should be a mention of it on the project page (like on the Coffee project page). (There might should be a mention of admin toolbar search on the project page, but I know I'm already pushing the edges of the scope of this issue 😇)

Thanks for your consideration :)

romainj’s picture

As we now have a Config Form for the Admin Toolbar Tools module we could add this kind of options.

paulocs’s picture

Assigned: Unassigned » paulocs
paulocs’s picture

StatusFileSize
new50.75 KB

In last dev version, the search field is always displayed.
Does this issue make sense as there is no shortcut to display (or not) the field.

Before work on it I would like to know if we should have the same approach in 8.x-1.x or if we should let it as it is.

8.x-2.x:
8.x-2.x

paulocs’s picture

Assigned: paulocs » Unassigned
romainj’s picture

@paulocs we should leave the 8.x-1.x as it is.

paulocs’s picture

@romainj what I mean is that #3056856: Create a keyboard shortcut to toggle access the search functionality was not ported to 8.x-2.x and to 3.x either. So this issue makes no sense any more. Only if we port the shortcut feature to those versions.

paulocs’s picture

Status: Active » Postponed

Moving issue status to Postponed and wait to #3211161: Show search field as toolbar item and not as text field. to be committed.

mlncn’s picture

Priority: Normal » Major
Status: Postponed » Active

The blocker is committed and `alt + s` opens the history menu item in Firefox so this is pretty important i think!

dydave’s picture

Version: 8.x-2.x-dev » 3.x-dev
Category: Bug report » Feature request
Priority: Major » Normal

We are accepting merge requests if anybody is interested in working on this.

Thanks!

ressa’s picture

dydave’s picture

So nice @ressa, as usual, of you to keep the ticket well documented based on the work from other issues 🙏

Adding here a few additional helpful comments and suggestions:

#3527344-12: New keyboard shortcuts do not work on MacOS:

3) More advanced mac users will know that alt = option / ⌥, but ideally it'd show "⌥ + a" instead of "alt + a". If this would be trivial to change based on parsing user agent strings that'd be useful. More of a minor/optional QoL issue.

#3527344-13: New keyboard shortcuts do not work on MacOS:
Issue summary:

Side note: When the search shortcut is disabled in the modules settings, the search input placeholder text still includes "(Alt+a)". Probably needs it's own issue.

I agree that the shortcut "tip" text could be improved — it shouldn't even be there if the shortcut has been disabled

#3527344-15: New keyboard shortcuts do not work on MacOS: Concerning the form settings for the hide/show toolbar shortcut:

it is a little odd it's tucked at the bottom of "Toolbar sticky behavior", since it's only tangentially related to that. Either the header should be something like "Toolbar visibility" or it should be in it's own section. It also wouldn't be terrible if the keyboard shortcuts were just in their own section instead of below what they're related to.

 

Let's see how we could organize and include these changes in the next merge requests.

Thanks again everyone for all the great help!