Page MenuHomePhabricator

Arrow keys break the Reply tool
Open, Needs TriagePublic

Description

Steps to reproduce:

  1. Click [reply] to a comment with the Reply tool. Type something. Leave your cursor in the middle of your text.
  2. Use the mouse/trackpad to switch to (or click on) the Source mode.
  3. Press Shift–Tab (should 'highlight' [put a box around] the Source tab.)
  4. Press the ← cursor key.
  5. See that it unexpectedly switches to the Visual mode and puts your cursor at the end of your text.
  6. Press the ← cursor key several times. See that the cursor doesn't behave normally.

Event Timeline

First reported at https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Talk_pages_project&oldid= 1006053606#Experiences by @Earwig in Chrome+Firefox on macOS and @Thryduulf in Firefox on Xubuntu, and verified by me in Safari on macOS.

It seems that you can get into a situation where the keyboard focus is on the Visual/Source mode selector, but the text input cursor is in the editor, and the editor looks like it has focus (indicated by the blue border).

The mode selector handles arrow keys to choose which element is active (it's a generic accessibility behavior for a tabbed interface, same as e.g. the tabs on Special:Preferences or various VE dialogs), and so it respond to you pressing arrow keys when you expect them to move the text input cursor.

To fix this, we need to make sure that the keyboard focus is really moved to the editor when it looks focussed.

Change 664354 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/DiscussionTools@master] Make sure the Visual/Source mode selector loses focus after switching

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

Change 664354 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Make sure the Visual/Source mode selector loses focus after switching

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

Ryasmeen added a subscriber: Ryasmeen.

The issue described in step 5 is still happening. Didn't notice anything abnormal during step.

On which wiki have you tested? It works correctly for me on https://en.wikipedia.beta.wmflabs.org/wiki/Talk:Main_Page. The patch is not yet deployed to production wikis (this will happen next week).

Oh, sorry, I think I misunderstood. You're saying that step 5 occurs like in the bug report (arrow keys switch modes while the mode selector is active), but step 6 does not (arrow keys work normally in the editor).

I think that's the expected behavior. The mode selector is a generic tabbed interface, same as e.g. the tabs on Special:Preferences or various VE dialogs, and you can use arrow keys to navigate within it.

Maybe we should change how that works though… With just two tabs, I can see how that would be unintuitive.

Change 667029 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/DiscussionTools@master] [WIP] Use buttons for mode selector to improve keyboard interactions

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

When I shift tab into the visual mode and then arrow over to source both source and visual appear as focused. What should happen is that the focus moves off the the visual and exclusively on to source. This is actually working but not on the first load if the first load is VISUAL.

Huh, I have no idea how you managed to do that, I can't find a way to get the interface into that state.

Can you try again with the next demo? I changed a bit how it works internally, maybe that resolves this problem too.

Test wiki created on Patch Demo by Matma Rex using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/51837ce13f/w/

I get an exception when trying to open the reply widget on this demo ^

Test wiki on Patch Demo by Matma Rex using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/51837ce13f/w/

Test wiki created on Patch Demo by Matma Rex using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/26e7cca889/w/

Change 667029 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Improve mode selector keyboard interactions

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

👍 that weird focusing issue isn't happening for me in the latest patch. Nice work @matmarex

Change 675579 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):
[mediawiki/extensions/DiscussionTools@master] Fix switching interface getting stuck after failing to switch

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

@iamjessklein I actually ran into that issue myself now and this patch fixes it. It would occur only after switching failed for some reason and you tried again.

so it looks ok but now i'm not trusting myself. maybe we need a third set of eyes - @DLynch @Esanders

Change 675579 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Fix switching interface getting stuck after failing to switch

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

I am not sure if the current behavior is expected. This is how it is behaving right now:

  1. Click [reply] to a comment with the Reply tool. Type something. Leave your cursor in the middle of your text.
  2. Use the mouse/trackpad to switch to (or click on) the Source mode.
  3. Press Shift–Tab, it should 'highlight' [put a box around] the Source tab if you were editing in Visual mode. If you were typing in Source mode this step will highlight the Source tab, while the cursor is still visible but not active in the description field. That does not look expected to me. @matmarex, can you confirm? Should the cursor stay visible?
  4. If you now Press the ← cursor key it does not unexpectedly switches to the mode.
  5. If you now start typing, nothing will get typed unless you click back and move the focus on the description field.

Press Shift–Tab, it should 'highlight' [put a box around] the Source tab if you were editing in Visual mode. If you were typing in Source mode this step will highlight the Source tab, while the cursor is still visible but not active in the description field. That does not look expected to me. @matmarex, can you confirm? Should the cursor stay visible?

No, it should not stay visible, thank you for noticing this.

I'll file a separate task about this though, because the original problem with arrow keys is fixed, and this task has been going on for long enough that some folks started using it as an example of what not to do. ;)