New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix navigation in inserter menu triggering writing flow #11088

Merged
merged 3 commits into from Oct 26, 2018

Conversation

Projects
None yet
4 participants
@talldan
Contributor

talldan commented Oct 26, 2018

Description

Fixes #9583

Particular keyboard interaction (up/down arrow keys) was causing focus to transfer out of the default block's insertion menu.

What causes this?
As far as I can tell, the ObserveTyping component is receiving those events and triggering the START_TYPING action, potentially causing focus to transfer to a block:

<div
onFocus={ this.stopTypingOnNonTextField }
onKeyPress={ this.startTypingInTextField }
onKeyDown={ this.startTypingInTextField }
>
{ children }
</div>

There might also be other event handlers acting on those events, but if so I haven't been able to determine what they are.

The fix
In this PR I've used the same technique as used in the LinkContainer to prevent this:

<form
className="editor-format-toolbar__link-container-content"
onKeyPress={ stopKeyPropagation }
onKeyDown={ onKeyDown }
onSubmit={ submitLink }
>

☝️ Here onKeyPress and onKeyDown events are used to prevent propagation of keyboard events outside of the popover. I've applied the same to the block insertion menu.

How has this been tested?

  • Manual testing
    1 - Open the inserter menu from the default block
    2 - Press the up or down arrow key
    Expected - focus should remain within the inserter search input
    Actual - focus is taken to a block

  • Added an e2e test to catch regressions

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.

@talldan talldan added this to the 4.2 milestone Oct 26, 2018

@talldan talldan self-assigned this Oct 26, 2018

@talldan talldan requested review from afercia and WordPress/gutenberg-core Oct 26, 2018

@talldan talldan changed the title from Fix/navigation in inserter menu triggering writing flow to Fix navigation in inserter menu triggering writing flow Oct 26, 2018

@afercia

This comment has been minimized.

Contributor

afercia commented Oct 26, 2018

@talldan thanks for working on this! Tested and works for me.

Worth noting left / arrow keys for input and textarea elements have been fixed in #9978 see isNavigationCandidate() in WritingFlow. That works only on the inserter search field though 🙂This PR makes the inserter fully operable with a keyboard (up / down arrow keys, scroll the scrollable div, any arrow keys press on any inserter element doesn't trigger WritingFlow any longer and that's good).

Just wondering if for the future a more abstracted solution could be valuable, as in: giving the ability to components to not trigger WritingFlow.

talldan added some commits Oct 26, 2018

Stop propagation of keyboard events from the block inserter
Preventing propagation ensures that ObserveTyping will no longer trigger the
startTyping action, which transfers focus back to the block level.
@youknowriad

This comment has been minimized.

Contributor

youknowriad commented Oct 26, 2018

Just wondering if for the future a more abstracted solution could be valuable, as in: giving the ability to components to not trigger WritingFlow.

Seems like something good to consider. I don't see it as blocking for the PR though.

@youknowriad

LGTM 👍

@talldan talldan merged commit 5f0ee02 into master Oct 26, 2018

2 checks passed

codecov/project 48.41% (-0.01%) compared to cb22c14
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@talldan talldan deleted the fix/navigation-in-inserter-menu-triggering-writing-flow branch Oct 26, 2018

@aduth

This comment has been minimized.

Member

aduth commented Oct 30, 2018

I think we should change the position of ObserveTyping from being a single top-level observer to being wrapped more granularly around the block's editable region, or perhaps even specifically as part of RichText.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment