Steps to reproduce: 1) Start typing in the URL bar such that a switch-to-tab match appears. 2) Focus that match using the keyboard. 3) Press opt+delete (or whatever keyboard shortcut deletes a word). 4) With the option key released, the switch-to-tab label remains in the URL bar. 5) Press enter. Expected results: The switch-to-tab label did not remain in the URL bar before pressing enter. The tab was navigated to the entered URL. Actual results: The tab was not navigated. Firefox switched to the tab corresponding to the now invalid match. Feel free to rename the bug to make it clearer.
It looks like _value is only updated when you highlight an entry in the popup, not when you type or remove text in the text field. So, after step 3 in comment 0, _value remains the value of the highlighted STT autocomplete result, so when _clearNoActions passes _value to _parseActionUrl, _parseActionUrl returns a STT. I noticed that after step 3 the popup loses its selection. This patch just checks if the popup still has a selection after keyup. If not, it doesn't try to re-set any action. Seems like the autocomplete controller should set the input's value when the popup's selection is lost just as it does when the selection changes, which would set _value to the visible value and get rid of the action. I also noticed that if you repeat steps 2 and 3, i.e., if you do 1, 2, 3, 2, 3, the entry remains highlighted and the text in the field doesn't match it. That seems like a separate bug.
Attachment #525177 - Flags: review?(gavin.sharp)
Comment on attachment 525177 [details] [diff] [review] lousy patch (In reply to comment #1) > I noticed that after step 3 the popup loses its selection. This patch just > checks if the popup still has a selection after keyup. This seems to only be true if the deleting results in the selected item being removed from the list - if it doesn't, the selection remains. So this isn't really a good solution. This explains your "repeat 2-3" results too, I think - when you delete something you make the list less specific (broader search), so when you go and select an entry from _that_ list and delete something from it, you're back at the generic result set, so the item you selected hasn't been filtered out.
Attachment #525177 - Flags: review?(gavin.sharp) → review-
I get bit by this almost every single day. Taking it to ease personal pain while stubbornly not changing workflow.
Assignee: nobody → fyan
Status: NEW → ASSIGNED
I won't have time to work on this unfortunately.
Status: ASSIGNED → NEW
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.