When I visit /usr/login using chrome I see the following error in the console output

I am not sure if this is a warning new to chrome.... or a bug new to drupal.

I was running the accessibility tests in chrome's lighthouse audit tool.

It can also be seen as a console warning if you have the chrome's aXe extension installed.

just something I want to tidy up.

11:50:55.344 login:1 [DOM] Found 2 elements with non-unique id #edit-submit: (More info: https://goo.gl/9p2vKq)

<input data-drupal-selector="edit-submit" type="submit" id="edit-submit" name="op" value="Log in" class="button js-form-submit form-submit">
<input class="search-form__submit button js-form-submit form-submit" data-drupal-selector="edit-submit" type="submit" id="edit-submit" value="Search">

Steps to reproduce (per digitaldonkey):

  1. Install Drupal standard profile
  2. Create a new user (Admin would use Seven them on user/#/edit. A new user uses Bartik theme by default)
  3. With the new user navigate to /user/*/edit and check for id="edit-submit" in page source

Expected behavior:
Only one element has id="edit-submit" id.

Observed behavior:
Two elements have id="edit-submit" id.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

martin107 created an issue. See original summary.

martin107’s picture

Title: #edit-submit in non-unique » #edit-submit is brittle use the BEM convention.
Component: user system » views_ui.module

I am changing the component field to view_ui.module

on the basis that views-admin.es6.js is the pain point.

Drupal.behaviors.viewsUiOverrideSelect::attach()

for me the aspect that must change that edit-submit is brittle and we need to use a BEM name.

"search-form--submit" because of the clash with edit-submit in the login page form

        const $context = $(context);
        const $submit = $context.find('[id^=edit-submit]');
        const oldValue = $submit.val();
digitaldonkey’s picture

Same in Drupal 8.4.4
Search form and user/#/edit collide

sensonicm’s picture

Can you describe the solution in more detail if it exists? Too proffessionalno you give an example.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

digitaldonkey’s picture

FileSize
20.41 KB

The solution is simple don't use the same HTML id attribute in two different forms.

The problem appears when you use Drupal standard Install profile (which includes the search form) and go to user/edit.
Search the page source for "edit-submit".

Also in Drupal Version 8.5.6

digitaldonkey’s picture

Update 8.6x

You can still reproduce in 8.6/8.7-dev

  1. Install Drupal standard profile
  2. Create a new user (Admin would use Seven them on user/#/edit. A new user uses Bartik theme by default)
  3. With the new user navigate to /user/*/edit and check for id="edit-submit" in page source
digitaldonkey’s picture

digitaldonkey’s picture

Status: Active » Needs review
martin107’s picture

Status: Needs review » Reviewed & tested by the community

Thank you Thorsten

That looks like the correct approach.

I can confirm that after manual testing the problem is resolved.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 8: 2938842-fix-duplicate-id-in-search-form-block.patch, failed testing. View results

digitaldonkey’s picture

But how I fix the tests?

It seems to be in
core/modules/settings_tray/tests/src/FunctionalJavascript/SettingsTrayBlockFormTest.php:186

digitaldonkey’s picture

digitaldonkey’s picture

Status: Needs work » Needs review
digitaldonkey’s picture

Status: Needs review » Reviewed & tested by the community

Tests now pass. As of martin107's comment changing to reviewed.

digitaldonkey’s picture

Issue tags: +DrupalEurope
digitaldonkey’s picture

Component: views_ui.module » search.module
Assigned: Unassigned » digitaldonkey
martin107’s picture

Yep +1 from me.

  • catch committed 0ea9fe9 on 8.7.x
    Issue #2938842 by digitaldonkey, martin107: #edit-submit is brittle use...
catch’s picture

Status: Reviewed & tested by the community » Fixed

Committed 0ea9fe9 and pushed to 8.7.x. Thanks!

  • lauriii committed 4b9cd2e on 8.7.x
    Revert "Issue #2938842 by digitaldonkey, martin107: #edit-submit is...
lauriii’s picture

Title: #edit-submit is brittle use the BEM convention. » Duplicate ID on the login page
Status: Fixed » Postponed (maintainer needs more info)
Issue tags: +Needs issue summary update, +Needs tests
+++ b/core/modules/search/src/Form/SearchBlockForm.php
@@ -108,6 +108,7 @@ public function buildForm(array $form, FormStateInterface $form_state) {
+      '#id' => 'search-form--submit',

This doesn't ensure the uniqueness since one block could be placed on the page multiple times. We should call Html::getUniqueId() for the ID. However, the default ID should already be unique so I'm not sure where the actual bug is. I tried to visit the login page but I couldn't reproduce this. Let's update the issue summary with the exact steps to reproducing the bug.

martin107’s picture

Issue summary: View changes

I have updated the issue summary with information on how I found the bug .. if you don;t mind installing a new chrome extension the fastest way to see if is to installed the aXe extension.

digitaldonkey’s picture

The bug is that the ID is hard coded to "edit-submit".

I agree that changing it to "search-form--submit" doesn't work if users place multiple search blocks. But at least it would then work out of the box.

@lauriii To reproduce please see #7. The point is if you have the search form on a user/*/edit page JS breaks (which happens when you are editing your profile as a non admin user in default config).

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

RedEight’s picture

Issue summary: View changes

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

andrewmacpherson’s picture

Status: Postponed (maintainer needs more info) » Closed (duplicate)
Parent issue: » #1852090: Cached forms can have duplicate HTML IDs, which disrupts accessible form labels

There are a bunch of issues which all report variations of this; the search an login forms are common scenarios, but it's a more widespread issue.

I see that the patch here was committed, but then reverted. Since there isn't a new patch here yet, I think we can close this issue as a duplicate of #1852090: Cached forms can have duplicate HTML IDs, which disrupts accessible form labels, which has much more detail about the accessibility problems, and several workarounds. I'll transfer issue credits for martin107 and digitaldonkey.

In Drupal\Component\Utility\Html::getUniqueId() there's a comment which says that we're intending to go to unique IDs only. The linked issue is #1090592: [meta] Use HTML5 data-drupal-* attributes instead of #ID selectors in Drupal.settings which only concerns itself with JS behaviours, not HTML validation or accessible name computation. I'm not clear if there are any blockers to using random IDs everywhere, but that's one of the approaches suggested in #1852090: Cached forms can have duplicate HTML IDs, which disrupts accessible form labels.