Page MenuHomePhabricator

UsersMultiselectWidget should throw error if unselected text is present onSubmit
Open, Needs TriagePublic

Description

For the Notifications Mute feature in Special:Preferences.

Problems

  • If a username is typed, but not selected from the list, the 'Save' button is active, but the input is thrown out.

Solution

  • If a username is typed but not 'entered' (e.g. hit the return key) then display an error to users when they slick 'Save'.

Existing error screenshot

Event Timeline

Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptAug 29 2017, 7:27 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

At the moment I prefer Solution C — it makes a safe assumption on behalf of the user and does not lose any data.

We should open a different ticket to solve for allowing users to provide invalid usernames, but I do not think this is a bug worth fixing at this time.

TBolliger updated the task description. (Show Details)Aug 29 2017, 7:31 PM

So @dmaza and I talked about this and T173973: Preferences/Notification, Save button stays disable when editing Block list covers your first point and the second does not seem like an issue. We looked at some other sites and couldn't find one where leaving unselected item would result in that item being saved. The only common solution is A, but I don't think it's strictly necessary as it looks like most sites just ignore it.

dmaza added a comment.Aug 31 2017, 6:12 PM

There is another solution which is to enable save only when the name is selected or removed instead of checking if there is input on the text field. This will also solve T173973: Preferences/Notification, Save button stays disable when editing Block list

So @dmaza and I talked about this and T173973: Preferences/Notification, Save button stays disable when editing Block list covers your first point and the second does not seem like an issue. We looked at some other sites and couldn't find one where leaving unselected item would result in that item being saved. The only common solution is A, but I don't think it's strictly necessary as it looks like most sites just ignore it.

Sounds fixed to me then!

@TBolliger

If a username is typed (not selected from the list), the 'Save' button is active and can be clicked, but the username will not be saved.

This is a broader issue and affects every form field. Actually just clicking somewhere inside of the fieldset (even not on a field) will activate Save.

If a non-existing username is typed, the 'Save' button is active and can be clicked, but the user name is not saved.

This seems typical of most multi-selects that I've seen.

In this case, the message to the user, e.g. "the entered username does not exists" will be helpful.

It might actually exist, i.e. I typed "David" and clicked save when really I meant "Davidwbarratt". This is why typically (from what I've seen) extraneous input is either ignored or errors.

It is worth noting that there is no username validation when a username is 'entered'

Right, because if it's on the list, it is returned from the API, so it has to exist (at least at the time of search).

I've seen several examples of pages warning when a user tries to navigate away with unsubmitted text in a field, (option A). I've also seen some examples of the UI making some assumptions on unsubmitted text (gmail does this with the 'address' field.)

Also, we don't have an explicit 'submit' button when a user provides a name, or instructions to hit return. It's fairly standard form behavior, but Wikipedia is used by all ages and experience levels.

I can think of a use case for someone forgetting to hit return (it's their first time muting and there's no explicit instructions on how to do so) but not a single use case of someone typing a username in the field, not intending to submit it, and then saving their preferences. The only case is "I typed a username then changed my mind" but this seems incredibly unlikely.

Overall, I don't think this is the most important problem in the world to solve. I think T173973 will cover enough of this.

dbarratt renamed this task from Minor UI problems with List type preference for Mute to UsersMultiselectWidget should throw error if unselected text is present onSubmit.Sep 6 2017, 1:40 AM
dbarratt reopened this task as Open.
dbarratt updated the task description. (Show Details)

@TBolliger I've simplified this issue so it is no longer a duplicate of T173973: Preferences/Notification, Save button stays disable when editing Block list since you bring up another issue that is important.

I've also seen some examples of the UI making some assumptions on unsubmitted text (gmail does this with the 'address' field.)

That's a great example.

I've seen several examples of pages warning when a user tries to navigate away with unsubmitted text in a field, (option A).

I believe only submit trips this error? I think if you navigate away with unsaved changes those changes are destroyed (for any field). Although, it looks like some browsers are smart enough to realize you have unsaved changes.

Regardless I think you bring up a legitimate point, so I'm opening this back up. :)

dbarratt updated the task description. (Show Details)Sep 6 2017, 1:45 AM

Low prio for AHT, removing Anti-Harassment tag.

I think we solved a very similar issue some years ago per T115010, with 9aba218a882f. Essentially, CapsuleMultiSelectWidget would automatically "accept" the typed input when it lost focus (was blurred). It seems this feature was lost in the MenuTagMultiselectWidget rewrite? (mw.widgets.UsersMultiselectWidget is based on OO.ui.MenuTagMultiselectWidget.) I see the same behavior with the plain widgets on https://doc.wikimedia.org/oojs-ui/master/demos/.

Restricted Application added a project: Growth-Team. · View Herald TranscriptOct 10 2018, 12:56 PM
SBisson moved this task from Inbox to External on the Growth-Team board.Oct 12 2018, 7:07 PM