QuantumBar: Pressing the down key should first go to the end of line, then open the results
Categories
(Firefox :: Address Bar, enhancement, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox67 | --- | fixed |
People
(Reporter: standard8, Assigned: dao)
References
Details
(Whiteboard: [fxsearch])
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
The behaviour of the existing URL bar when the down key is pressed is to first go to the end of line, then to open the results.
Comment 1•6 years ago
|
||
May want to check if this is Mac only behavior, on Windows I don't see that, unless steps differ. STR?
Reporter | ||
Comment 2•6 years ago
|
||
Just found it, this is a Mac specific thing:
STR
- Type a few letters in the address bar
- Move the cursor to earlier in the text
- Press the down arrow
Expected Results
- Cursor moves to end of text, with the popup not opening.
Actual Results
- Popup opens, cursor moves to end of text.
Note, I think there's another issue where doing left-arrow doesn't close the popup. Will need to check if we have a bug for that.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 4•6 years ago
|
||
Assignee | ||
Comment 5•6 years ago
|
||
(In reply to Mark Banner (:standard8) (afk until Friday) from comment #2)
[...]
- Press the down arrow
Expected Results
- Cursor moves to end of text, [...]
Ehsan, do you know what makes this behavior platform-specific / where this is controlled in Gecko?
Comment 6•6 years ago
|
||
Yes, this is platform-specific.
Everywhere besides Mac, VK_DOWN on input controls is mapped to cmd_moveDown https://searchfox.org/mozilla-central/source/dom/xbl/builtin/ShortcutKeyDefinitionsForInputCommon.h#10. On Mac, there is no specific mapping for that key on input controls https://searchfox.org/mozilla-central/rev/dc0adc07db3df9431a0876156f50c65d580010cb/dom/xbl/builtin/mac/ShortcutKeyDefinitions.cpp#9. I don't remember off the top of my head what happens when there is no built-in mapping, I suggest breaking in TextInputListener::HandleEvent() to see what event handler is picked up for the keypress event on Mac.
Comment 8•6 years ago
|
||
bugherder |
Comment 9•6 years ago
|
||
I just found this autocomplete test covering this behavior, that was added in bug 231754. Could you please check we implemented the same behavior and there are no misses?
https://searchfox.org/mozilla-central/source/toolkit/content/tests/chrome/test_autocomplete_mac_caret.xul
Description
•