Page MenuHomePhabricator

MenuTagMultiselectWidget with outline input doesn't open menu after first selection
Closed, ResolvedPublic

Description

As of v0.21.0 MenuTagMultiselectWidget with outline input doesn't open up any more when clicking the focussed input field after first tag selection from menu.


From @Schnark on duplicate T193119
I noticed this on the API sandbox, but I can also reproduce on the demos, so this isn't API-sandbox-specific.

  1. Go to https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query
  2. Switch to the query page.
  3. Click the prop input, and select an item, e.g. categories from the menu.
  4. Note that the menu closes (which is probably as expected).
  5. Now try to get the menu open again.

Expected:
All (or at least some) of the following methods work, and will re-open the menu:

  • Click the input again (while it is still focused)
  • Press the cursor key for right, top, or down.
  • Press the enter key.

Actual:
None of these methods will open the menu, only the following methods work:

  • Click somewhere to blur the input, and then focus it again.
  • Press the cursor key for left, and then for right.
  • Press the spacebar.

Event Timeline

Volker_E created this task.Apr 17 2017, 6:50 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 17 2017, 6:50 PM
Volker_E updated the task description. (Show Details)Apr 17 2017, 6:51 PM
Jdforrester-WMF moved this task from Backlog to Next-up on the OOUI board.Apr 17 2017, 8:02 PM
Volker_E triaged this task as Medium priority.Aug 23 2017, 8:59 PM

Wikimedia Resource Center is experiencing this issue as well.

Volker_E raised the priority of this task from Medium to High.Apr 24 2018, 11:52 PM
Mooeypoo added a comment.EditedApr 25 2018, 1:03 AM

We should definitely fix it. The menu hides itself after choose, and only reopens on focus - but in these cases, the focus is ALREADY on the input, so it doesn't reopen. We need to fix it.

However, if experiencing issues, the immediate quickfix is to add the following config variable when instantiation a MenuTagMultiselectWidget:

{
	menu: {
		hideOnChoose: false
	}
}

This will make sure that the menu at least doesn't immediately closes on choose, which will mitigate the issue.

For a fix, I think we have two main options:

  • We can set hideOnChoose: false by default (as an override, even) to MenuTagMultiselectWidget, since it doesn't quite make sense for it to vanish on choose, especially since this is a multiselect widget, so we expect the user will choose more than one item anyways. Alternatively,
  • We can unfocus the input when the menu closes, forcing the user to refocus if they need it to reopen.

I must at this point state that I'm extremely against #2, but I had to spell it out. I think, honestly, that #1 is sensible. In the context of this widget, I think there's no sense in having the menu close after the first pick. The menu should remain open (and be filtered if the user types stuff in, etc) until the user clicks away from the widget.

@Volker_E what do you think?

@Mooeypoo I agree that option #2 doesn't sound convincing from an experience perspective.
But there are also some issues with #1:

  • How do people realize that it's a MultiselectWidget when there are no items chosen yet? They come across a thing that looks like an input field with an autocomplete menu (or similar). So they choose one and suddenly the dropdown remains open. How does one close it?
  • I see a similar issue with a very long list of menu items, that could easily make people upset
  • And, that's something we should do in any case, there should be a way to highlight selected items in the menu. Going into another task…

@Mooeypoo I agree that option #2 doesn't sound convincing from an experience perspective.
But there are also some issues with #1:

  • How do people realize that it's a MultiselectWidget when there are no items chosen yet? They come across a thing that looks like an input field with an autocomplete menu (or similar). So they choose one and suddenly the dropdown remains open. How does one close it?

The second they choose an item and the menu doesn't close, the user understands the widget allows for more items.

You close it by moving away from the widget -- clicking out of it.

  • I see a similar issue with a very long list of menu items, that could easily make people upset

I don't know; I think it makes sense. If the menu is part of the widget, then it makes sense it's part of the widget's "active" state. When you're in it, it's there, and if you want to turn it off, move out of it -- by tabbing or by clicking out.

  • And, that's something we should do in any case, there should be a way to highlight selected items in the menu. Going into another task…

Yes, well...

Change 491643 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[oojs/ui@master] MenuTagMultiselectWidget: 'hideOnChoose' should be set to false

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

Change 492428 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[oojs/ui@master] [wip] Un-wtf the MenuSelectWidget's behavior for focus and toggle

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

Volker_E moved this task from Next-up to Reviewing on the OOUI board.Feb 27 2019, 3:32 AM

Change 491643 merged by jenkins-bot:
[oojs/ui@master] MenuTagMultiselectWidget: 'hideOnChoose' should be set to false

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

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 closed this task as Resolved.Mar 22 2019, 7:20 PM

This patch landed in MediaWiki master in time for 1.33.0-wmf.23, which will go out to Wikimedia production from 2019-03-26.