Fragment identifiers on Modules page and Permission page don't work

[olafgrabienski]

Description of the bug

A "Permissions" links on the Modules page leads to the Permissions page. The link points to the permissions of a specific module, but you don't arrive there and stay at top of the page.

Steps To Reproduce

To reproduce the behavior:

1. Go to the Modules page (admin/modules).
2. Look for an enabled module which has a "Permissions" link, e.g. the "Field UI".
   The path is admin/config/people/permissions#module-field_ui.
3. Click on the "Permissions" link.

Actual behavior

You arrive at top of the Permissions page.

Expected behavior

You arrive at the targeted section with specific module permissions, e.g. #module-field_ui.

Additional information

• Backdrop CMS version: 1.32.1

[olafgrabienski]

As stated above, when I click on a link like admin/config/people/permissions#module-field_ui, I arrive at top of the Permissions page. When I then put the cursor at end of the URL in the browser address bar and hit Enter, I arrive at the targeted section. So, the fragment identifier seems to be correct.

I guess the fragment identifier doesn't work in a link because the focus is set to the Filter at top of the page, see the following screenshot:

---

The filter was introduced in #980.

---

Update 04.11.2025: It turned out that the Modules page itself has the same issue: fragment identifiers don't work because of an autofocused filter at top of the page.

[NormPlum]

I can confirm the focus on the search box is the issue: https://github.com/backdrop/backdrop/blob/1.x/core/modules/user/js/user.permissions.js#L64

Removing the trigger('focus') part makes anchor links work properly.

[olafgrabienski]

Thanks for confirming, @NormPlum. I'm open to provide a PR, but I'm not sure what exactly to remove: just the whole line 64?

And do you think it makes sense to remove the focus part, or is there maybe an alternative that allows to keep the focus if people arrive at the page 'normally' (without anchor link)?

[NormPlum]

It might come down to a choice between keeping focus, or keeping anchor links working.

There is apparently a way to focus an element without scrolling to it:

element.focus({
  preventScroll: true
});

But support isn't perfect, and I'm not sure how to set preventScroll with the trigger method Backdrop uses.

[indigoxela]

It might come down to a choice between keeping focus, or keeping anchor links working.

Autofocus is often just an annoyance, so personally, I'm leaning towards getting rid of it.

In this case it's done with JavaScript in Backdrop.behaviors.moduleFilter.

Getting rid of that .trigger('focus') fixes it.

So, instead of $input.trigger('focus').on('keyup', filterModuleList); we could use $input.on('keyup', filterModuleList); and the annoying autofocus should be gone.

But we'd need consensus to drop that autofocus there.

[indigoxela]

Or... we could make the focus conditional. Only if we don't jump to a specific module permission, set the focus. 😉

[indigoxela]

Oh, I slightly misunderstood... but that's not bad, because the identical problem happens on two different pages:

• admin/config/people/permissions
• admin/modules/list

My PR fixes both now.

How to test:

• Go to admin/config/people/permissions and there should be focus on the search input (it has a focus halo).
• Go to admin/config/people/permissions#module-config and you should jump to the config section - no focus on the search input

Similar on admin/modules/list - add a hash like #module-config and you should jump to the right section.

In fact, the same pattern's used in the Layout module - when filtering available blocks in the Layout "Add block" dialog - but there this doesn't cause any problems, as there couldn't be any url hash inside that dialog. 😉

[NormPlum]

I like that PR, very nice solution. But why did you put a comment explaining it in one file and not the other?