Page MenuHomePhabricator

Tokenizer input field loses focus after tab completion
Open, WishlistPublic


(I noticed this bug on projects, but it may occur in other places you can enter multiple complete-able items into a textbox.)

I wanted to enter a bunch of people to a new project. So I went to, and in the "Add members" textbox started to type a username. The completion popped up, and I hit tab to accept it, which worked fine.

What I expected to happen next is that the input box would retain the focus, with the cursor right after the name that was just entered.

What actually happened is the focus went somewhere else (to the window root?) and I had to re-click in the textbox to start entering my next name. Not the end of the world, but annoying.

Event Timeline

csilvers created this task.Dec 3 2014, 12:08 AM
csilvers raised the priority of this task from to Needs Triage.
csilvers updated the task description. (Show Details)
csilvers added a project: Projects.
csilvers added a subscriber: csilvers.
chad renamed this task from Text input field loses focus after tab completion to Tokenizer input field loses focus after tab completion.Dec 3 2014, 3:54 AM
chad triaged this task as Wishlist priority.
chad edited projects, added PHUI; removed Projects.

For me, focus goes to the next input, which seems correct. That is:

  • If I press tab, the selection is confirmed and focus moves to the next input.
  • If I press return, the selection is confirmed but focus does not move.

The intent is that tab means "done with all selections; move to the next input" and return means "done with this selection".

This behavior seems consistent across forms.

Are you seeing a different behavior, or do you not think this behavior is reasonable? It seems reasonable/desirable to me.

Oh! I didn't think of hitting enter (I'm used to tab-completing instead).

Enter works great.

The intent is that tab means "done with all selections; move to the next input" and return means "done with this selection".

In, say, gmail, if you're composing a new email and you start typing in the 'to' field, suggestions will pop up, and if you want to take the selection you hit 'tab', at which point it autocompletes and puts the cursor next to the token to wait for the next name to be input -- the same as how enter works for phabricator. I just tested now and enter works the same as tab for gmail.

Personally, I prefer the gmail semantics. The current phabricator semantics are a bit confused, I think, because while in completion mode -- that is, while phabricator is suggesting auto-completes -- tab both finishes the autocomplete and moves to the next input: it seems like tab is being passed through to both the autocomplete logic and to the element logic. To me, it makes more sense that while autocompleting, all inputs are passed just to the autocomplete logic, and in that logic both tab and enter mean "accept this autocomplete".

That said, I have a happy workaround now that I know to use enter. I do still think changing the tab behavior while autocorrecting would be reasonable. An alternative would be to make the enter behavior easier to discover, though I don't know a reasonable way to do that.

I don't think expecting people to hit enter is entirely reasonable – I'm personally scared that it'll submit the form, which is what enter ordinarily does in a form (except in a textarea).

chad added a subscriber: chad.Dec 3 2014, 11:31 PM

tab and enter both seem correct / commonly used in this UEX, at least from my limited testing of a few mail clients, gmail, facebook, etc.