🇺🇸United States @charles belov

charles belov → created an issue.

Actually, thinking about it, if "None" causes use of the global setting, what if someone actually wants 0ms?

Would the correct list for a user actually be:

• None
• 0ms
• 250ms
• 500ms
• 750ms
• 1000ms
• 1250ms
• 1500ms
• 1750ms
• 2000ms

Sorry for the delay; I was out of office. Thank you very much for the patch; it works for me. I would not have a problem with leaving it as a sub-module that had to be activated as a separate step. My only comments would be to change the wording of:

Custom hover intent timeout in milliseconds for the admin toolbar. Leave empty to use the global setting.

to

Custom hover-intent timeout in milliseconds for the admin toolbar. Leave as "None" to use the website setting.

and:

Admin Toolbar Hover Intent Timeout

to

Admin Toolbar Hover-Intent Timeout

I tested as follows on simplytest.me:

• Drupal core 11.x-dev
• admin_toolbar 3.x-dev
• https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/199.patch

Steps:
1. Log in as admin
2. Go to /admin/modules
3. Filter on Toolbar
4. Check Admin Toolbar Hover Intent Timeout Per User
5. Click Install
6. Add two users test and test2 as Content Editors
7. Go to /admin/config/user-interface/admin-toolbar
8. Set hoverIntent timeout (ms) to 750ms
9. Click Save configuration
10. In a private window, log in as test
11. Set hoverIntent timeout (ms) to 2000ms
12. Click Save
13. Interact with the menu

Expected and actual results: Moving the pointer off the menu leaves the menu open for about two seconds

14. In another browser, log in as test
15. Interact with the menu

Expected and actual results: Moving the pointer off the menu leaves the menu open for about 3/4 second

@dydave Thank you for the check-in. Looks good to me. On my test on simplytest.me:

• Drupal Core 11.x-dev
• Module Admin Toolbar 3.x-dev
• https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/198.patch

I see all the edits I expected to see.

Correcting component.

Thank you! Noting the link text dialog (such as if the link text is "here") already puts the issue up front, although it would benefit from moving the edit button up immediately below the issue.

charles belov → created an issue.

charles belov → created an issue.

@ressa Thank you! That's very clear.

Clarified how to act if you are on gitlab and the fork does not exist.

Making it clear that the proper procedure is to create the fork from the issue page, not from gitlab (see my previous comment).

When I attempt to Edit a single file in gitlab, I (sensibly) get the message

Fork to make changes

You're not allowed to make changes to this project directly. Create a fork to make changes and submit a merge request. 

If I then click Fork, I get the message:

 Fork Error!

You tried to fork project / admin_toolbar but it failed for the following reason:

– Limit reached You cannot create projects in your personal namespace. Contact your GitLab administrator.

Please add documentation for this issue, including instructions on how to contact the GitLab admin.

https://git.drupalcode.org/-/profile/ssh_keys redirects to my Drupal.org profile.

https://git.drupalcode.org/-/user_settings/ssh_keys is the current URL for my drupalcode.org keys.

Sorry about the delay in responding; I was out of office.

Thank you for pushing various changes to the development version. Regarding the current wording:

I believe that it is an improvement to use camel case on "hoverIntent" so that it will be read properly by screen readers. However, I feel it is better to use less technical language than assume that the person doing the particular configuration is familiar with the JavaScript. I'd really prefer to see it as two separate words which describe the actual functionality rather than the internal name, just as Drupal usually describes the friendly name rather than the machine name.

I additionally added hyphens where hover intent is being used as a modifier for another word, and made one other suggested edit to focus on the behavior rather than on the technology which achieves that behavior.

So:

Toolbar hover-intent behavior
Provides a smoother user experience, where only menu items which are paused over are expanded, to avoid accidental activations.
Disable hover intent to respond instantly to the pointer position.
Enable hover intent
Hover intent timeout (ms)
milliseconds
Sets the hover-intent trigger timeout (steps of 250).
The higher the value, the longer the menu dropdown stays visible, after the mouse moves out (default: 500ms).

Separately, re "Hide or show the toolbar with shortcut (Alt + p)" that that is the key combination for Windows. On Mac it is Option + p. That said, I just tested it and it works.

Sorry for the delayed response; I was out of office.

I am in Quality Assurance, not Development, thus unable to comment on this as it is beyond my knowledge of Drupal or the contribution environment.

Yes. That would be the simplest solution. Placeholder text is a known usability/accessibility issue and is poorly implemented in browsers.

charles belov → created an issue.

charles belov → created an issue.

charles belov → created an issue.

I've updated the issue summary to include steps I missed and interspersed screen captures to show what I'm getting.

charles belov → created an issue.

Sorry about overlooking this. Reopening as it is still an issue in 11.x-dev, as tested on simplytest.me.

A search on date for core-supplied fields returns only 5 fields:

• Last comment time Comment Statistics Date and time of when the last comment was posted.
• Updated/commented date Comment Statistics The most recent of last comment posted or entity updated time.
• Authored on Content The date and time that the content was created.
• Has new content Content Show a marker if the content is new or updated.
• Authored on Content revision The date and time that the content was created.

A search on time for core-supplied fields returns 8 fields:

• Last comment time Comment Statistics Date and time of when the last comment was posted.
• Updated/commented date Comment Statistics The most recent of last comment posted or entity updated time.
• Authored on Content The date and time that the content was created.
• Changed Content The time that the node was last edited.
• Authored on Content revision The date and time that the content was created.
• Changed Content revision The time that the node was last edited.
• Revision create time Content revision The time that the current revision was created.
• Use count File Usage The number of times the file is used by this entity.

Also filed a child issue ✨ Make it easier for site admins to configure image metatags accessibly Active

@damienmckenna: Thank you for that suggestion. The issue with placing this warning in the Editoria11y module is that that information is displayed to editors, who would not likely have permission to edit the metatag settings. Further, since the metatags appear on every page of a particular content type, every page of that content type would get the warning message.

charles belov → created an issue.

Updating to current version.

@anthonyroundtree: I don't believe that you were overthinking this. I just encountered the problem, leading me to this issue. Some pages are very busy and it would be good to be able to audit changes in them. While the usual use case would be to find when a particular change happened, it still is currently not possible to compare the last revision on one page to the first revision on the next page. If that's when the change happened, it would be tedious to try to reconstruct the issue without being able to compare across revision pages.

@uri_frazier: Thank you for the workaround. My one concern would be whether it would create site performance issues on a page which was exceptionally active, say, was updated weekly or even daily, over the course of a year.

I forgot to test the escape key.

It technically isn't a keyboard trap because you can return to the toolbar by pressing the escape key twice.

However, you have to know that you need to press the escape key twice and not just once. I can imagine and editor pressing the escape key once, noting that it doesn't work to escape the apparent keyboard trap, and going on to try something different.

It would be better if it worked by pressing the escape key just once. I will change the issue title and summary to reflect that.

Thank you for the screen capture. I was misunderstanding what you wanted to happen to the long titles.

I just tested this and simplytest.me, and it works well with regard to the proposed change.

charles belov → created an issue.

Apologies for my accidental munging of related issues. I think I've restored them but someone please check.

The question I have is whether a keyboard-only user can get to this wonderful new icon and activate it without knowing what the shortcut is to get to the toolbar. Please see related issue 🐛 Cannot tab to CKEditor5 toolbar Active .

@cilefen I have a Mac mini and my keyboard is not a Mac-specific keyboard. The keyboard (emphatically) does not have an Fn key. However, for the record, macOS has a setting under System Settings, Keyboard, Keyboard Shortcuts..., Funtion Keys reading "Use F1, F2, etc. keys as standard function keys" and I have that setting turned on.

I have confirmed that option plus F10 does in fact move focus from the field content to the toolbar. Noting I found the language concerning a menu confusing as I do not see a menu anywhere in the CKEditor5 edit area, leaving me to use the wrong key combination.

I thought about closing this issue as works as designed but I see a related issue ✨ Implement AccessibilityHelp plugin for CKEditor5 Active which presents an interesting conundrum: there is about to be an accessibility indicator in the toolbar which tells about what the various keyboard shortcuts are. The question is whether there is any way to get to it without knowing the option/Alt-F10 shortcut to begin with.

So I'm going to leave this open until people who are involved with that issue can have a look at this.

@cilefen Thank you for the link to that reference. According to that reference, I would expect to be able to get to the toolbar on my Mac by pressing option and F9 together. However, that is not working for me to get to the toolbar. My keyboard does not have an Fn key and I am normally able to use the function keys without it.

There is still the discoverability issue. I will file a separate issue for a link to the documented key strokes that you provided.

charles belov → created an issue.

charles belov → created an issue.

What is WHCM? Please expand the acronym on first use. I'm guessing it has to do with contrast, but I'm not sure because the acronym is opaque to me.

I'd like to review this as to whether I agree with the proposed solution, but I'm having trouble getting the relevant patch to apply on simplytest.me. I've posted a comment ✨ Drastically improve Drupal's default linking experience in text fields Needs work on ✨ Drastically improve Drupal's default linking experience in text fields Needs work concerning that failure. Hopefully it will be easy to resolve so that I can proceed with my test.

I'm not having any luck applying https://git.drupalcode.org/project/drupal/-/merge_requests/10036.patch to 11.3.x-dev on simplytest.me in order to test this. The build fails. Is there a different version of Drupal core that I need to be applying this to or a different patch version that I need to be applying?

Would it be possible to post the screen recording as a video rather than as a animated GIF? It goes by too fast for me to follow and I can't pause it or run it at half speed because it's an animated GIF.

There would also be the question, when the number of items is limited, how to determine which items get shown in the auto suggest and which items get excluded. You might need to ensure that shorter titles are shown, because if two pages have matching titles up to a certain point, you can exclude the shorter title by adding more characters. But if the shorter title is not shown, there is no way to exclude the longer title by removing characters, so you would never be able to see the page with a shorter title in the auto suggest.

Regarding:

Verify that the parent links on each level of the admin toolbar have an "Expand" button next to them. For top level parent links, this should be a down-pointing blue chevron. For lower levels, it should be a right-pointing blue chevron.

Having the chevron direction vary by level presents a cognitive challenge for me. It would be better if the chevron direction were consistent across levels, as well as consistent with the operating system behavior. In the Mac Finder, the chevron points right on unexpanded items and down on expanded items. Windows Explorer does not present a chevron.

charles belov → created an issue.

charles belov → created an issue.

charles belov → created an issue.

Would we want this to be an option? Maybe somebody does want to see if a computed field changes. If it does change, I understand that they would have to figure out why from the other fields.

This is still an issue. I have updated the issue description to reflect the current state as of Drupal 11.2-dev.

charles belov → created an issue.

Files no longer display an icon with a title attribute when inserted. Closing as outdated.

charles belov → created an issue.

Closing as unable to reproduce in the current version of Drupal. No icon is added when the file is inserted into the CKEditor WYSIWYG.

charles belov → created an issue.

charles belov → created an issue.

With regard to my quote

I believe that issue has lessened now that I'm using the workaround below

I am using layout.frame_rate set to 3 in Firefox.

@junaidpv Thank you for the patch. Aside from the testing issue raised by @smustgrave, it gets us much of the way there.

The drop-down works, substituting the English-friendly terms on all pages.

In the view preview and the view page, I do see From and To.

I don't know whether it is feasible, but in the Views UI itself, we still get the technical labels. It would be nice is those were plain English as well:
Min
Max
Min placeholder
Max placeholder

Tested the patch on simplytest.me, and I'm not seeing the local tasks menu.

Steps:
1. Go to https://simplytest.me/
2. In the project name Field type admin
3. Choose admin_toolbar from the auto suggest
4. In the version drop down, choose 3.x–Dev (I also tried 3.6.1, with the same result.)
5. Click advanced options
6. Leave Drupal core at 11.2.1
7. In the patch field, paste https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/127.patch
8. Click Launch Sandbox
9. Copy log before it redirects to the site
10. Locate 127.patch in the log

Expected and actual results:

6876a2366cd631d7cc96a161# /bin/sh -c cd stm && composer patch-add drupal/admin_toolbar "STM patch 127.patch" "https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/127.patch" --no-update
Gathering patches from patch file.
The patch was successfully added.

11. Log into the site as admin

Expected result: I am on the admin user page /user/1. I see the following menus, not necessarily in this sequence:

• Manage
• This User
• Shortcuts
• admin
• Announcements

Actual result: I am on the admin user page /user/1. I see the following menus:

• Manage
• Shortcuts
• admin
• Announcements
• Edit

12. Go to /admin/config/user-interface/admin-toolbar

Expected and actual result: I see the default options for the admin toolbar module, indicating to me that the admin toolbar module is active.

13. Create a new basic page (Content, Add content, Basic page, type "test" in title field, Save)

Expected result: /node/1 has the following menu items:

• Manage
• This Content
• Shortcuts
• admin
• Announcements

Actual result: /node/1 has the following menu items:

• Manage
• Shortcuts
• admin
• Announcements
• Edit

Updating issue to follow current template.

I actually did update the summary. Is there anything else you need?

Updated to Drupal 11.2.x. Still relevant.

I have tested the patch in Firefox and I believe the focus indicator gives good contrast.

In that second image, is there a reason one of the inactive tabs has a white background? (Image resize)

charles belov → created an issue.

Thank you for that update. Here are my findings, tested in Firefox with factory settings:

1. The focus indicators for the most part are much better.
2. For some strange reason, only part of the focus indicator is showing up on some items. The worst of this is for Content, which only has a focus indicator on one side, making it ambiguous as to whether it applies to Content or to Structure. For the others, it shows up on three sides, which, while aesthetically unpleasant, is at least unambiguous.

Please see the screen recording that I took for the current state of patch 149 → . (Note: Sorry about needing to download the video. drupal.org doesn't let me embed it, and it is longer than 5 seconds so I can't convert to an animated GIF without violating WCAG 2.1 for Pause, Stop, Hide.)

charles belov → created an issue.

@quietone Thank you! I had only looked in the module, not in the library.

@smustgrave I'm not sure what additional information you need. The code is still in 11.x and is therefore potentially an issue. Of course, the patch is out of date.

I just did a test on simplytest.me, which is apparently not a Windows machine.

• File name on my Mac: file name with special chars /*?"<>|.txt
• File name once uploaded to simplytest.me: file%20name%20with%20special%20chars%20%3A*%3F%2522%3C%3E%7C.txt
• File name as shown in the Windows Edge address bar: file%20name%20with%20special%20chars%20%3A*%3F%2522<>%7C.txt
• File name as downloaded to Windows 11: file name with special chars ___%22___.txt

So, it's not an issue that files originally stored on a non-Windows machine can't be accessed by a Windows machine.

My concern would be if the site were moved from a non-Windows host to a Windows host that the files would no longer be accessible. However, I have not tested this and, as QA not developer, don't have a way to test this hypothesis.

Added Windows 11 wording for setting.

There doesn't appear to be any corresponding code in the file module for Drupal 11. Closing as obsolete.

Also noting that the Drupal 10 version doesn't show a use count, so I won't restate this as a Drupal 10 Redirect issue.

I think the tabbing is greatly improved and works predictably. I do notice one issue:

If I am on /admin/structure and I tab to Structure, not the caret to the right of Structure, the focus indication disappears and I'm left to wonder where the focus is.

I notice Structure is a link on /admin/structure, so technically it needs to be capable of being tabbed to. I'm not a fan of pages linking to themselves, but I'm guessing that is outside the scope of the current issue.

But if it's a link, and can be tabbed to, it needs to show the focus.

Similarly, if I am on /admin/structure/display-modes/form and tab to Structure, Display Modes or Form Modes, the focus appears to disappear.

Actually, as it turns out, the underline toggles on focus/loss of focus. This is inconsistent with how focus is indicated in the rest of the Admin Toolbar and it took me several tries to notice that. It isn't user-friendly, at least to this user, and adds to cognitive load, taking my focus away from my task.

Please do not over-engineer focus indication.

Indeed, thank you. Closing as duplicate of #3057679.

Yes, I do think that a best practice would be not to override the browser's focus indicator ever, as it increases cognitive load for the website visitor. The next best practice would be to be consistent, not to have every contrib module come up with its own focus indicator. I recognize that the admin site is distinguished from the visitor site.

@mgifford, would you want to weigh in on this?

Please note my comment on Focus indication clashes with active tab indication 🐛 Focus indication clashes with active tab indication Active . There is code in patch 138 which conflicts with the patch 149 for that issue.

Thank you for the clarification. I might have to file an issue against core then.

Anyway, yes, it passes. I must say a 4.5:1 contrast of background to text, while compliant, is a bit hard for me to read. If you could also darken the text on focus to #000000, that might help. That said, it's compliant. Unfortunately, there's no way to lighten the green background without breaking 3:1 contrast with the white.

There does seem to be a conflict with patch 138. For the following steps:

Steps:
1. Go to https://simplytest.me
2. Enter admin_toolbar for the project
3. Select 3.x-dev
4. Open the advanced options
5. Keep Drupal core 11.2-dev as the core version
6. Paste patch https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/149.patch
7. Click add additional patch
8. Paste patch https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/138.patch

Expected result: I get both the improvements in tabbing sequence provided by patch 138 and the contrast improvements provided by patch 149

Actual result: There is no evidence that admin toolbar is active. However, if I go to Extend, it shows that the admin toolbar module is in fact active.

And for the following steps:

Steps:
1. Go to https://simplytest.me
2. Enter admin_toolbar for the project
3. Select 3.x-dev
4. Open the advanced options
5. Keep Drupal core 11.2-dev as the core version
6. Paste patch https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/138.patch
7. Click add additional patch
8. Paste patch https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/149.patch

Expected result: I get both the improvements in tabbing sequence provided by patch 138 and the contrast improvements provided by patch 149

Actual result: I get the improvements in tabbing sequence provided by patch 138 but not the contrast improvements provided by patch 149

Actually, I'm seeing inconsistent behavior as I navigate through the admin toolbar menu.

Focus on specific menu and submenu items are indicated with the green highlight.

Focus on Manage, Shortcuts, the user name, and Announcements are indicated by a thin underline.

Focus on Edit appears to use the browser default.

It would be good to unify the focus indicator so users don't have to hunt it out and perceive changes to it as they navigate through the menus. I would expect the focus indicator to be consistent through the entire menu navigation.

It took me a while to figure out the following: Light gray in a menu item indicates that there a menu subordinate to it. That is, Content, Structure, Configuration, and Reports are gray while Appearance, Extend, People, and Help are not. Additionally, in the Content and other such menus, if an item in that menu has a submenu, there is a chevron indicating the presence of more items, so the light gray there is cosmetic and does not require contrast remediation.

However, the menus for Content, Structure, Configuration, and Reports do not have a chevron, so the light gray currently cannot be considered cosmetic. Either the contrast between gray and white needs to be improved to 3:1 (while retaining a 4.5:1 contrast between text and background) or a down chevron needs to be added to Content, Structure, Configuration, and Reports to indicate the presence of an additional menu.