Page MenuHomePhabricator

Namespaces multiselect widget selects an item on input change *before* filtering the items according to the changed input
Closed, ResolvedPublic2 Estimated Story Points

Description

This is easiest to explain through examples (note that these will behave differently if you type too quickly!):

  • Type 't' into an empty widget and press <enter> - a tag is created for (Main), the first item on the unfiltered list, then the list is filtered to namespaces beginning with 't'
  • Type 'ta' into an empty widget and press <enter> - a tag is created for Talk, the first item on the list of namespaces beginning with 't', then the list is filtered to namespaces beginning with 'ta'
  • Type 'to' into an empty widget and press <enter> - a tag is created for Talk, the first item on the list of namespaces beginning with 't', then the list is filtered to namespaces beginning with 'to'

Another symptom of the same problem (from T214197):

  • There seems to be a timing/debounce bug with the widget: if I type 'user' (all lowercase) fairly quickly then "User" is not highlighted (grey background). If I type slowly everything works as expected.

Here, it would seem that the events are debounced and (Main) is selected first, then the list is filtered to namespaces beginning with 'user'


Expected behavior

  • If a user types quickly, the suggestions should still highlight the best match. (There can be a few (micro?) second delay for performance reasons, if needed.)
  • If no items are selected in the dropdown, pressing <enter> should do nothing.

Event Timeline

Tchanders triaged this task as Medium priority.Feb 13 2019, 8:45 PM
Tchanders created this task.

Change 492407 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[oojs/ui@master] MenuTagMultiselectWidget: Fix highlight and scrolling to item behavior

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

Change 496613 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[oojs/ui@master] MenuTagMultiselectWidget: highlightOnFilter only if not allowArbitrary

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

Change 492407 merged by jenkins-bot:
[oojs/ui@master] MenuTagMultiselectWidget: Fix highlight and scrolling to item behavior

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

Change 496613 merged by jenkins-bot:
[oojs/ui@master] MenuTagMultiselectWidget: highlightOnFilter only if not allowArbitrary

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

Change 498143 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] Update OOUI to v0.31.1

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

Change 498143 merged by jenkins-bot:
[mediawiki/core@master] Update OOUI to v0.31.1

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

Jdforrester-WMF subscribed.

The underlying change in OOUI landed in MediaWiki master in time for 1.33.0-wmf.23, which will go out to Wikimedia production from 2019-03-26. Leaving open for the team to use however.

@Mooeypoo Do you expect this to be fixed now? It appears to behave according to the acceptance criteria as far as I can tell.

  • There seems to be a timing/debounce bug with the widget: if I type 'user' (all lowercase) fairly quickly then "User" is not highlighted (grey background). If I type slowly everything works as expected.

@Mooeypoo

On Firefox 60 and Chromium 57, most of the time nothing is highlighted until it has filtered to only one namespace. Does not matter if I type quickly or slowly.

If nothing is highlighted (and there are 2 or more namespaces in the dropdown) and I press the down key, nothing gets highlighted but if I then press enter the (Main)/(Article) namespace is selected and appears as a pill.

See:

Sometimes the top item does get highlighted. I don't know why it does sometimes and not others.

Expected behavior

  • If a user types quickly, the suggestions should still highlight the best match. (There can be a few (micro?) second delay for performance reasons, if needed.)

As above, often items are not highlighted at all. Speed of typing does not seem to matter (in my case).

  • If no items are selected in the dropdown, pressing <enter> should do nothing.

This is true.

Retesting on Firefox 60, Chromium 73, Edge and Safari 12. On https://en.wikipedia.beta.wmflabs.org.

Expected behavior

  • If a user types quickly, the suggestions should still highlight the best match. (There can be a few (micro?) second delay for performance reasons, if needed.)

I saw this happen every time, regardless of how quickly I typed, if I copy-pasted or if I used an autotyper.

  • If no items are selected in the dropdown, pressing <enter> should do nothing.

One item was always selected in the dropdown (initially (Article)/(Main)).

On Firefox 60 and Chromium 57, most of the time nothing is highlighted until it has filtered to only one namespace. Does not matter if I type quickly or slowly.

If nothing is highlighted (and there are 2 or more namespaces in the dropdown) and I press the down key, nothing gets highlighted but if I then press enter the (Main)/(Article) namespace is selected and appears as a pill.

Trying again today, I cannot reproduce either of these behaviours on Firefox 60, Firefox 66, Chromium 73, Edge or Safari 12.

Perhaps I had some old javascript cached in my browser? Therefore, I am going to move this on.