zotero/zotero — pull request #417 by willsALMANJ (2013-11-10 20:42:57+00:00)
Title: Set completeselectedindex to true in itembox and tagsbox editors to more...

... closely mirror html input forms.

Setting this attribute is not a perfect match to the behavior of html input forms, but it is close. With it true, highlighting a completion in the popup by using the arrow keys automatically sets that completion's text as the text content of the textbox. If you then tab away, the previously existing Zotero code then uses that completion text to set the item field or tag. With html forms, the text isn't entered into the textbox on highlighting the completion but is entered into the textbox when you tab away.

The only situation where this difference matters in practice is if you select a completion with the arrow keys and then click somewhere else to move the focus away from the completion popup. With a web form, the completion is not entered into the textbox in this case, but for the XUL textbox the completion text is already entered on selection so it stays in there. However, if you are just using the keyboard for everything, the XUL textbox and the html form are identical -- selecting a completion and then hitting or uses the selected completion (with keeping the cursor in the current textbox and focusing the next one (creating it first if you were on the last tag)) and escape hides the popup without entering the completion. Also, selecting a completion by clicking it works the same as before.

So to summarize, the only behaviors that are different (I think) are

1. Hitting after selecting a completion: now enters that completion for the tag rather than just the text you entered for tag.
2. Clicking away from the textbox and completion popup after selecting a completion leaves the completion text in the textbox rather than the text that has been entered by the user.

#1 is the purpose of this patch. I don't think #2 matters much one way or the other -- both behaviors leave some amount of text in the textbox, and hitting cancels creating/changing the tag in both cases.

I looked through the autocompletion source for a while. I think this is as close as one can get to the behavior of an html form without using a custom autocompletion controller (but I could have overlooked something).

By the way, while we are on this subject, is it desired behavior for the tagsbox to lose focus when you edit an existing tag other than the last tag and then hit , rather than just saving that tag value and then focusing the tag that was the next tag (I say "was the next tag" because the order might shift when you edit the existing tag)? That behavior has always annoyed me. It comes up if you are typing in tags one by one (so not alphabetical order) and you mistype one (often by hitting on an autocompletion out of habit). If you tab back up to it, select the correct autocompletion, and then hit twice (once to accept the completion and once to enter the new tag), the tagsbox loses focus. I might not run into this situation much any more if this patch gets accepted and my default key for entering tags changes from to , but it still strikes me as unexpected behavior (the tagsbox losing focus).