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):
- Install Drupal standard profile
- Create a new user (Admin would use Seven them on user/#/edit. A new user uses Bartik theme by default)
- 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.
Comment | File | Size | Author |
---|---|---|---|
#13 | 2938842-fix-duplicate-id-in-search-form-block.patch | 1.4 KB | digitaldonkey |
#8 | 2938842-fix-duplicate-id-in-search-form-block.patch | 622 bytes | digitaldonkey |
#6 | drupal-editsubmit.gif | 20.41 KB | digitaldonkey |
Comments
Comment #2
martin107 CreditAttribution: martin107 as a volunteer commentedI 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
Comment #3
digitaldonkey CreditAttribution: digitaldonkey at ConsenSys commentedSame in Drupal 8.4.4
Search form and user/#/edit collide
Comment #4
sensonicm CreditAttribution: sensonicm commentedCan you describe the solution in more detail if it exists? Too proffessionalno you give an example.
Comment #6
digitaldonkey CreditAttribution: digitaldonkey at ConsenSys commentedThe 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
Comment #7
digitaldonkey CreditAttribution: digitaldonkey at ConsenSys commentedUpdate 8.6x
You can still reproduce in 8.6/8.7-dev
Comment #8
digitaldonkey CreditAttribution: digitaldonkey at ConsenSys commentedComment #9
digitaldonkey CreditAttribution: digitaldonkey at ConsenSys commentedComment #10
martin107 CreditAttribution: martin107 as a volunteer commentedThank you Thorsten
That looks like the correct approach.
I can confirm that after manual testing the problem is resolved.
Comment #12
digitaldonkey CreditAttribution: digitaldonkey at ConsenSys commentedBut how I fix the tests?
It seems to be in
core/modules/settings_tray/tests/src/FunctionalJavascript/SettingsTrayBlockFormTest.php:186
Comment #13
digitaldonkey CreditAttribution: digitaldonkey at ConsenSys commentedComment #14
digitaldonkey CreditAttribution: digitaldonkey at ConsenSys commentedComment #15
digitaldonkey CreditAttribution: digitaldonkey at ConsenSys commentedTests now pass. As of martin107's comment changing to reviewed.
Comment #16
digitaldonkey CreditAttribution: digitaldonkey at ConsenSys commentedComment #17
digitaldonkey CreditAttribution: digitaldonkey at ConsenSys commentedComment #18
martin107 CreditAttribution: martin107 as a volunteer commentedYep +1 from me.
Comment #20
catchCommitted 0ea9fe9 and pushed to 8.7.x. Thanks!
Comment #22
lauriiiThis 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.Comment #23
martin107 CreditAttribution: martin107 as a volunteer commentedI 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.
Comment #24
digitaldonkey CreditAttribution: digitaldonkey at ConsenSys commentedThe 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).
Comment #26
RedEight CreditAttribution: RedEight at 95Visual commentedComment #29
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer commentedThere 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.