Page MenuHomePhabricator

In search bar, Home and End keys should move caret, not selection in suggestions
Closed, ResolvedPublic3 Estimated Story Points

Description

Many users of TypeaheadSearch are expecting keyboard behaviors that Codex does not currently implement. These behaviors include:

  • Allowing Home and End keys to move the cursor to the start or end of the text input, respectively
  • Allowing Shift+Home and Shift+End to select from the current cursor location to the start or end of the text input
  • Anything else?

Initial bug report

(from @Jack_who_built_the_house )

If I type text in the new search bar and want to move the caret to the beginning of it, I can't do it by pressing Home. Instead, the first item in the suggestion list gets selected:

image.png (776×594 px, 101 KB)

The same is true for the End key. (Page Down and Page Up don't move the selection.)

If, by any chance, that was done deliberately, I find that extremely intrusive, annoying, and contradicting the principle of least astonishment.

Technical Considerations

TypeaheadSearch delegates most keyboard interactions to its embedded Menu component. The latter component was designed to handle Home and End keypress events in its own way – by moving the menu selection to the first or last item. However, this interaction may not be appropriate for components that include both a Menu as well as a TextInput. This includes TypeaheadSearch but also Lookup and Combobox. It is pretty straightforward to change these components so that they stop delegating Home/End keypress events to the Menu component without changing the latter.

The TextInput component itself may or may not need to change – we should do some cross-browser and cross-OS testing to make sure the component is handling keyboard interactions in the expected way.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Pols12 added a subscriber: Pols12.

I think this is a regression (maybe in July or June).

Having said that I know close to nothing about codex: I could track this down to the keydown event handler on the TypeaheadSearch component, which delegates to Menu.handleKeyNavigation. That function handled "Home" and "End" explicitly (together with other keys), and highlights menu items consequently. For the menu, this is intentional and was implemented in https://gerrit.wikimedia.org/r/c/design/codex/+/812081, as part of T310556. I believe that if you are navigating menu items, it makes sense for Home and End to highlight respectively the first and last item. However, that is unwanted while you're typing. Maybe the TypeaheadSearch component should not let Menu handle those keypresses unless a menu item is selected (and even them, I'm not sure if it should, because if you happen to highlight an item then the resulting behaviour could be confusing). Adding people from T310556 as subscribers here.

stjn added a subscriber: stjn.

Well, merging the text from my duplicate task now:

I think, given what’s said on W3C WAI Authoring Practices Guide about the combobox pattern, that choosing to implement Home/End keys as the means to traverse the combobox is incorrect. Search field is by definition editable, so users should be able to go back/forward to edit whatever they want here. Even Shift+Home/Shift+End combinations, the one that select text, do not work in New Vector’s search, which makes the experience annoying for people who use those keys (like me). Please remove key handling for Home/End keys in New Vector’s search.

I hope Desktop Improvements team will one day react to this task.

Change 831995 had a related patch set uploaded (by Eric Gardner; author: Eric Gardner):

[design/codex@main] [WIP] TextInput, TypeaheadSearch: Change cursor position on home/end keypress

https://gerrit.wikimedia.org/r/831995

egardner changed the task status from Open to In Progress.Sep 13 2022, 9:55 PM
egardner set the point value for this task to 3.

Test wiki created on Patch demo by EGardner (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/a0fc647172/w

Also created a Codex documentation site:
https://patchdemo.wmflabs.org/wikis/a0fc647172/w/build/codex/demos

A patch to adjust this behavior is in development. Typeahead Search was originally developed as part of the Desktop Improvements project, but now the search component itself comes from Codex – the WMF's new UI component library. Codex is maintined by the Design Systems Team as opposed to the Web Team, and it looks like this task fell through the cracks for the last few weeks.

@Daimona's diagnosis of the problem is correct – we designed the Menu component to respond to "home" and "end" keypress this way. This behavior may not be appropriate when a Menu component is used alongside a Text Input (like in the TypeaheadSearch component).

In addition to TypeaheadSearch, Codex also contain Lookup and Combobox components where a Menu and a TextInput exist side-by-side – we should decide if we want all of these components to operate the same way now.

Our TextInput component previously has not handled "home" and "end" keypress at all, but this can be added.

To see the patch applied to a demo wiki in patch demo, just enable the Vector 2022 UI via URL params: https://patchdemo.wmflabs.org/wikis/a0fc647172/wiki/Main_Page?useskin=vector-2022

To see the patch applied to a demo wiki in patch demo, just enable the Vector 2022 UI via URL params: https://patchdemo.wmflabs.org/wikis/a0fc647172/wiki/Main_Page?useskin=vector-2022

Thank you, as far as I can see there's still a defect in the patchdemo: home and end do not work together with shift, i.e., if you place the cursor at the end and hit shift+home to select all the text, the shift key will be ignored and it will just move the cursor to the start (without selecting anything).

Thank you, as far as I can see there's still a defect in the patchdemo: home and end do not work together with shift, i.e., if you place the cursor at the end and hit shift+home to select all the text, the shift key will be ignored and it will just move the cursor to the start (without selecting anything).

I think the crux of this issue is going to be figuring out exactly what keyboard behaviors the underlying TextInput component in Codex needs to implement. We'll need to clearly specify them either on this ticket or on a new one.

We should probably compare the following:

  • Behavior of standard <input> elements (HTML only, no JS)
  • Behavior of OOUI TextInputWidget
  • Behavior of Codex TextInput component

We'll dig into this a bit further and will work on getting a fix out soon.

egardner removed the point value for this task.
egardner moved this task from Requests to Needs Refinement on the Design-Systems-Team board.

Test wiki created on Patch demo by EGardner (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/ea621a0e60/w

Also created a Codex documentation site:
https://patchdemo.wmflabs.org/wikis/ea621a0e60/w/build/codex/demos

Test wiki on Patch demo by EGardner (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/a0fc647172/w/

In order to meet users' expectations, we should follow the direction set by this ticket and avoid delegating the Home and End keyboard interaction to the Menu component whenever an input is present.

In terms of Codex work, this would imply:

  • TextInput: We should allow standard single line text editing functions. 1. Using Home and End keys to move the cursor to the start or end of the text input; 2. Allowing the use of shift+Home and shift+End keys to select the content.
  • Combobox, TypeaheadSearch, Lookup (and other combinations of Menu with an editable input): Following ARIA's Authoring practices, 1. Home and End should always return the focus to the input. Single line text edit capacities should be derived from TextInput (see above).; 2. Control+Home and Control+End should allow accessing the first and the last option of the menu, respectively. This is technically optional, but will come in handy in menus with long scroll.
  • Select (and other combinations of Menu with a non-editable trigger elements such as buttons): Following ARIA's Authoring practices, Home and End should be enabled to allow moving the focus to the first and the last option in the menu, respectively. This is unless we'd prefer implementing arrow key wrapping, which is the default behavior of the Codex Menu at the moment: pressing the up arrow in the first option takes you to the last item, and vice-versa (pinging @Volker_E for confirmation).

Note: Weirdly enough, I can already reproduce all the wanted behaviors described above on macOS Monterey. Both in our demo and in production, I can use cmd+left/right arrow and shift+cmd+left/right arrow to move the cursor back to the input and select text, respectively. I believe, though, that these are not the actual home and end equivalents on mac (apparently they should be fn+right/leftarrow instead). I tested this in the latest versions of Chrome, Safari and Firefox.
I can also already use fn+cmd+arrow to move the focus to the first and the last row of a menu. These seem to be indeed the right equivalents of ctrl+home and ctrl+end.

Thanks @Sarai-WMDE! I've updated my patch to implement the behavior you asked for in Combobox, Lookup and TypeaheadSearch. It works for me on my Ubuntu laptop with real Home/End keys, but I'd also appreciate it if someone could test that it also behaves as desired on MacOS. You can test here (that shows TypeaheadSearch, follow the links in the sidebar for Combobox and Lookup). I also tried creating a PatchDemo so we could test the Vector search, but unfortunately PatchDemo is broken right now; I'll create one once that's fixed.

Change 836939 had a related patch set uploaded (by Catrope; author: Catrope):

[design/codex@main] TextInput: Suppress keydown events for Home/End

https://gerrit.wikimedia.org/r/836939

Test wiki created on Patch demo by Roan Kattouw (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/b94b165200/w

Also created a Codex documentation site:
https://patchdemo.wmflabs.org/wikis/b94b165200/w/build/codex/demos

Thanks @Sarai-WMDE! I've updated my patch to implement the behavior you asked for in Combobox, Lookup and TypeaheadSearch. It works for me on my Ubuntu laptop with real Home/End keys, but I'd also appreciate it if someone could test that it also behaves as desired on MacOS.

Hey @Catrope. Thanks so much for the changes! The link shared in your comment directed me to a 400 error page, so I tested in the following environment:
https://836939--wikimedia-codex.netlify.app/components/demos/typeahead-search.html#search-wikipedia-articles

Hope that's the correct link! Following the patch, I can still use the equivalent key combinations to move my cursor and select the text in the inputs of TypeaheadSearch, Combobox and Lookup 👍🏻 Nevertheless, I'm not able anymore to use fn+cmd+left/right arrows to navigate to the first and last options of the menu, which would be ideal (specially combined with the new "infinite" scroll functionality).

Sarai-WMDE added a subscriber: Sarai-WMDE.

Oops, sorry, that should have been https://831995--wikimedia-codex.netlify.app/components/demos/typeahead-search.html#search-wikipedia-articles . That one uses different code than 836939, but they should behave the same (in theory; it's the same logic just in a different place in the code).

Thanks for pointing out that fn+cmd+left/right don't work for you. I've updated both patches to check for cmd as well as ctrl, and tested on my partner's Macbook, where it seems to work now. Please test if it now works as desired.

Hi Roan! Sorry for the late reply. I tested again the "Search Wikipedia articles" demo in the shared link, and unfortunately fn+cmd+left/right doesn't seem to work. I asked Bárbara for help to confirm this, and the key combination also doesn't work for her in the demo build (although it does in the main demo site, like for me). We're both using macOS Monterey (v 12.4+).

I'm not sure of how to proceed: Do we want to make sure that this works as part of this task, since it could be considered a regression (we could specify this in the description, i.e. replace "Anything else?")? Or would it be better to open a separate ticket, since this is not a specific AC of this task?

Here's what I am seeing now when I run this patch locally:

Up/down arrow keysmoves selected item in menu
Left/right arrow keysmoves text cursor
pgup / pgdn keysdoes nothing
Cmd + left arrow / cmd + right arrowmoves cursor to start or end of text input
Option + left arrow / Option + right arrowsame as above
Shift + left arrow / shift + right arrowmoves text selection
Cmd + fn + left arrow / cmd + fn + right arrowMoves to first or last menu item

Change 831995 abandoned by Eric Gardner:

[design/codex@main] Combobox, Lookup, TypeaheadSearch: Fix Home/End behavior

Reason:

Abandoned in favor of https://gerrit.wikimedia.org/r/c/design/codex/+/836939

https://gerrit.wikimedia.org/r/831995

Change 836939 merged by jenkins-bot:

[design/codex@main] TextInput: Suppress keydown events for Home/End

https://gerrit.wikimedia.org/r/836939

Change 849191 had a related patch set uploaded (by VolkerE; author: VolkerE):

[mediawiki/core@master] Update Codex from v0.2.1 to v0.2.2

https://gerrit.wikimedia.org/r/849191

Change 849191 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v0.2.1 to v0.2.2

https://gerrit.wikimedia.org/r/849191

Has this task received design sign-off? I know that @Sarai-WMDE took a look but I want to make sure we have official approval.

Has this task received design sign-off? I know that @Sarai-WMDE took a look but I want to make sure we have official approval.

@egardner I've checked the demo and fn+cmd+left/right is still not working for me. Watch the video.

@egardner I've checked the demo and fn+cmd+left/right is still not working for me. Watch the video.

Are you using a Mac? On my Mac, fn + cmd + left moves the selection to the first result in the list, and fn + cmd + right selects the last result in the list. This works consistently across Firefox, Safari, and Chrome.

I wonder if internationalization settings or different keyboard configurations could be impacting the behavior here?

I think this patch should be moved to QA, to allow for a more systematic testing of behavior on various OS and browser combinations.

Additionally, I'd like to invite @Jack_who_built_the_house and any other users who originally noticed this bug to try out the Typeahead Search demos on this page in the Codex Docs site: https://doc.wikimedia.org/codex/main/components/demos/typeahead-search.html. It would be helpful to know if the search boxes here now demonstrate the keyboard behavior you were originally expecting. Thanks!

I checked the Codex Docs site, and current Enwiki (with vector-2022) and both now work as I expected (in Linux). I.e. Ctrl+Arrows jump from between word-breaks, Ctrl+Shift+Arrows selects words, and Home/End keys jump to the start/end of the text. Thanks!

For the record, I just tried the key combinations on macOS again, and they work as expected for me too. Tested using Chrome v107, Safari v15.6 and Firefox 105 on macOS Monterey. Would agree to move the task to QTE.

  • Tested using Chrome v106 and Firefox 106

Up/down arrow keys --> moves selected item in menu (Passed)
Left/right arrow keys --> moves text cursor (Passed)
Cmd + left arrow / cmd + right arrow --> moves cursor to start or end of text input (Passed)
Option + left arrow / Option + right arrow --> same as above (Passed)
Shift + left arrow / shift + right arrow --> moves text selection (Passed)
Cmd + Fn + left arrow / Cmd + Fn + right arrow --> moves to first or last menu item (Passed)

  • On Safari v14 and v16:

Cmd + Fn + Left arrow -> opens www.apple.com website.

@egardner can you please take a look at this again?

  • On Safari v14 and v16:

Cmd + Fn + Left arrow -> opens www.apple.com website.

@egardner can you please take a look at this again?

This is browser-provided behavior (we're certainly not triggering it in our own code). So I think in the context of this patch it is fine. The goal is for our Input component to stop getting in the way of expected browser and OS-level behavior (whatever that may be).

I agree! Thanks for the context (also mentioned here).

Moving this to Product sign-off.

Test wiki on Patch demo by Roan Kattouw (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/b94b165200/w/

Test wiki on Patch demo by EGardner (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/ea621a0e60/w/