Left / Right Arrow key navigation in the one-off search buttons breaks convention (should move caret, not select one-off)
Categories
(Firefox :: Address Bar, enhancement, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox82 | --- | verified |
People
(Reporter: karl9242, Assigned: mak)
References
Details
(Keywords: blocked-ux)
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0
Steps to reproduce:
Select the address bar (control-L) and input some text (Such as "test"). Press the "up" arrow and it will change focus fist to the search settings button, and then to the "This time, search with..." widget at the bottom of the address bar.
Actual results:
Now if you use the left and right keys, it will no longer move your cursor left and right in the text you entered ("test") instead it will change which search engine is selected. If you keep hitting right or left then it will keep on just changing which search engine is selected (the list wraps). The up and down arrows also change search engine (Up selects the previous search engine, right selects the next one)., but they do NOT wrap Pressing control-L will SELECT all the text in the address bar again, but entering left and right arrow keys afterwards will still continue changing which search engine is selected. CLICKING in the text in the address bar will change where text input happens but also does not make left and right arrow keys work in the address bar again.
The only way to get the left and right arrow keys to work properly again is by hitting down or up arrows repeatedly until keyboard focus moves back to the address bar. Note that only the "up" and "down" keys work - Because left and right wrap in the bottom you can hit them all you want and they'll never get you out of the search engine selection area.
Why is this a problem exactly? Many reasons.
-
if you accidentally hit the up arrow key without realizing it then you're now in a situation where the left and right keys you're used to using do what they're supposed to any more, and the only way to get things to work again is by noticing that focus has changed, and hitting the up / down arrows an appropriate amount of times to refocus on the text input area so you can finally move your cursor to the right place in a URL and edit it. Fat fingering the "up" key shouldn't break your flow while using a browser.
-
It's not consistent with how left / right keys work in the rest of the suggestions dropdown. If I enter "test", then a bunch of suggestions pop up below. Hit the "down" arrow to select one of them, and that suggestion's URL will now be in the address bar. Clicking left / right at this point will move the CURSOR in the address bar, just like it always has. But if you click down a few more times until focus is on the search engine suggestions, then left / right no longer move the cursor.
Expected results:
The best option I can think of for making the new GUI work is as follows: Left / Right keys always move the cursor in the actual text which is visible in the address/search bar. This happens regardless of whether you have a suggestion focused, or a search engine focused. Up and down arrows still move you to the next or previous suggestion in the suggestions dropdown, and through the search engine suggestions once you reach the bottom. If someone wants to search with twitter instead of with google, they'd just enter their search term and then hit the up arrow 3 times to select "twitter" from the search engine list, then click enter. This is no slower than how you'd do it with the current behaviour (click up once to highlight the "search engines" area, and then click left twice to select "twitter" from the list)
This is better for a bunch of reasons. It keeps the meaning of the left and right arrow keys while focused on the address bar consistent - they always move your cursor in the address bar.
It means that if you enter something you want to search for, you can edit it at any time. Let's say you typed "African swallow" in the address bar, hit the "up" key a few times to select "search from wikipedia", and then realized that you actually wanted to search for "European swallow" instead. The way things are set up right now you'd have to press the down arrow multiple times to get back into text entry mode, change African to European in the address bar, and then click "up" a few times to select the wikipedia search engine again. If you adopt my suggestion then someone can edit their search term without needing to unselect and then re-select the search engine they want to use first.
Comment 1•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Assignee | ||
Comment 2•5 years ago
|
||
I agree with you, only up/down (and similar) should move through results, even if they are layed our horizontally.
This is historical behavior of one-off buttons, and we must evaluate whether breaking it would be a problem or not. That's an UX question.
Assignee | ||
Updated•4 years ago
|
Comment 6•4 years ago
|
||
It would be nice to fix this along with the other one-off changes in update2. I'm going to mark it blocking the update2 metabug so it doesn't fall off our radar. We can remove it later if we don't want it.
Updated•4 years ago
|
Assignee | ||
Comment 7•4 years ago
|
||
I can take this and put it behind a pref, default to no horizontal navigation with update2, but can be re-enabled with the feature pref.
Assignee | ||
Comment 8•4 years ago
|
||
Assignee | ||
Comment 9•4 years ago
|
||
We can wait to land this until Tuesday, I put a question in the UX document to ensure it gets approved before landing.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 10•4 years ago
|
||
Verdi approved landing this, because left/right on one-off buttons pretty much constitutes a mouse trap disallowing the user to further modify the search string.
Comment 11•4 years ago
|
||
Comment 12•4 years ago
|
||
bugherder |
Comment 13•4 years ago
|
||
I verified this issue using 82.0a1 (2020-09-14) on macOS 10.13 and Windows 10 x64.
Adrian could you help me with Ubuntu verification?
Comment 14•4 years ago
|
||
Verified as fixed on Ubuntu 18.04 64-bit using 82.0a1 2020-09-17.
Marking as verified based on above comment.
Description
•