Page MenuHomePhabricator

Overlapping dropdown menus on Type selector
Closed, ResolvedPublicBUG REPORT

Description

I get overlapping dropdown menus when using the type selector. It might be a browser issue. I am using current Chrome on MacOS.

Steps to Reproduce:

Go to https://notwikilambda.toolforge.org/wiki/ZObject:Z12368

Click edit (you need to be logged in)

Delete the Z2K2 key

Add a new Z2K2 key

Actual Results:

Now when I type in the Type selector 'T', I get the following two drop downs to select from (only the lower one seems to work)

Screenshot 2021-02-01 at 16.08.50.png (660×703 px, 123 KB)

Expected Results:

Only the lower drop down should appear.

Event Timeline

My guess is that Chrome is trying to be helpful and offers some autofill, and might be told not to.

Hmm Chrome autofill might be doing that, yeah.

There's an ongoing loooong discussion about how to control this behavior with poor success:

  • Some people report that adding the autocomplete="off" in the input worked for some versions of Chrome, but it seems not to be doing the trick anymore.
  • Others have opted for adding autocomplete="one-time-code" which seems to completely disable autofill.
  • Apparently from Chrome 81 it was added the autocomplete="chrome-off"which would likely disable autofill, however some developers online seem to be reporting that this works only five time... wait, whaaat? According to them, chrome tracks how many times this attribute is rendered on the page, and only allows five fields to disable autofill, ignoring the attribute after that.
  • Seems like the solution that is being reported effective right now to tackle this issue is to add the chrome-off attribute dynamically on focus.

I haven't been able to replicate this, as I only use Chrome for very specific (and never form-based) pages, but maybe you can try if any of these attributes work.

As mentioned in the closed T276356, when selecting an element in the fake dropdown, the event is not being captured and so there's no value being accepted for the component even if the input form has a valid option as value.

Considering that whatever fix we find can be dodged by a new version of chrome (and also considering their apparent obsession to show their own autofill dropdown no matter what), we should be cautious and expect the error in T276356 to happen. As a side to trying to avoid the autofill to appear, we should capture the event thrown by chrome autofill dropdown element being selected, and allow the component to understand this event and handle the data so that the user doesn't face confusing behaviors.

Per StackOverflow (https://stackoverflow.com/questions/15738259/disabling-chrome-autofill), autocomplete="off" is now working as expected. I was able to properly disable the autofill using this method.

However, this component appears to be a part of wvui, so I believe the patch would need to be upstream, correct?

Also, the component includes an aria-autocomplete="list". While having an aria value of "list" and actual value of "off" does get the correct functionality, I'm not certain of the impact on a11y for doing this. I think we'd need to check with the correct team why they wanted to set this aria role before suggesting our change.

Change 674949 had a related patch set uploaded (by Lindsay Wardell; author: Lindsay Wardell):
[mediawiki/extensions/WikiLambda@master] Update AutocompleteSearchInput, add autocomplete="off"

https://gerrit.wikimedia.org/r/674949

Change 674949 merged by jenkins-bot:
[mediawiki/extensions/WikiLambda@master] Update AutocompleteSearchInput, add autocomplete="off"

https://gerrit.wikimedia.org/r/674949