Having a search block on every page is a very common use-case. However Drupal assigns an edit-submit id attribute to the button, and an edit-keys id attribute to the search input. That means we have a possibility to have a collision of duplicate ids on every page where we add a form apart from the search block form. That happens when this cached search block is rendered in a new context, because the search form is not processed to avoid id collisions, resulting in both forms having the edit-submit id attribute.
Providing unique IDs for this one form would substantially improve accessibility for most sites.
- Enable caching
- Assign core search block to all pages
- As anonymous, visit a page without any forms other than search block
- Now, visit a page with search block and additional forms, e.g. login page
Just changing the IDs on the search form would fix this specific and common problem.
- Set a different id attribute on the submit button (other than edit-submit)
- Set a different id attribute on the input (other than edit-keys)
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
cilefen commentedThis looks like a duplicate of #1852090: Cached render elements can have duplicate HTML IDs. Can you confirm?
Comment #3
shivansunfire commentedIt is not a duplicate of that issue.
The scope of the referenced issue you are asking about, is to discuss and find a solution to replace Drupal's prevention of id collision, on all forms. There is a tough debate going on about cache invalidation for form IDs, and no consensus has been reached yet, leading to a situation where this has been stuck for 11 years!
I have opened this issue specifically for the Search module, because here is where we are finding let's say 99% of the collisions, due to having a search block in every page is so common. So the goal of this issue is to provide a simple solution: change the ID just in this form. We have been forced to do that in alter hooks for 10+ years, so let's fix this now with specific IDs for the form Search module provides, while we keep the other issue open to continue discussing (it's been almost 1 year without movement there), and maybe one day we'll have a better cache solution or ID prevention globally.
Comment #4
cilefen commentedComment #6
shivansunfire commentedComment #7
smustgrave commentedSeems to have caused some nightwatch failures.
Also think we will need our test showing this issue.
Comment #8
shivansunfire commentedIt looks like the current solution is failing accessibility tests because when duplicating the block form on a page, elements get the same id. I've verified that Drupal's way of preventing duplicates id by adding dashes and numbers only works with "edit-keys" and "edit-submit", not other specific ids.
So we would need to add a different random hash / number to the id string.
Comment #9
smustgrave commentedCurious does https://www.drupal.org/project/drupal/issues/2894747 solve this issue?
Comment #10
shivansunfire commented@smustgrave, no it doesn't look like it have anything to do with it.
Comment #13
quietone commentedThe Search Module was approved for removal in #3476883: [Policy, no patch] Move Search module to contrib .
This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.
The deprecation work is in #3565780: [meta] Tasks to deprecate the Search module and the removal work in #3565783: [meta] Tasks to remove the Search module.
Comment #14
quietone commentedThe Search Module has moved from core to contrib,