Switch-to-tab occurs even after input has changed from the match




8 years ago
5 years ago


(Reporter: fryn, Unassigned)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment)

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.
Posted patch lousy patchSplinter Review
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)
Blocks: 596485
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-
See Also: → 594122, 610761
Duplicate of this bug: 753494
See Also: 594122, 610761
I get bit by this almost every single day.
Taking it to ease personal pain while stubbornly not changing workflow.
Assignee: nobody → fyan
I won't have time to work on this unfortunately.
Assignee: fyan → nobody
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.