Modal Component: Up / Down Keys close modal spawned from editor canvas

[jeryj]

KeyPress events from the modal on the editor canvas are bubbling to editor. This means that when you press the up or down arrow keys:

• the arrow keypress bubbles to the editor canvas,
• which uses the arrow keys to navigate blocks,
• which then closes the modal because the focus of the new block is outside the modal.

To reproduce
You can see this by trying to resolve a broken block within the editor canvas.

• Add a paragraph block
• Click Edit HTML (from the triple dot more menu in the toolbar)
• Add some invalid HTML to break the block, like <p> <p>Text</p>
• On the broken block, click "Resolve" which opens a modal from within the context of the editor canvas
• Press an up or down arrow
• The modal is closed

Expected behavior
The modal should only be closed Escape keypress. Other keypresses should not bubble outside the modal. Global keypresses should still be able to be used, like Save (command + s).

Potential Solution

I'm not sure if this has unintended consequences, but adding a e.stopPropagation() at the end of the modal keydown handler, it seems to work to block the arrow keys from closing the modal while still a blocking Up/Down from closing the modal.

https://github.com/WordPress/gutenberg/blob/master/packages/components/src/modal/frame.js#L57-L61

[WunderBart]

I'm not sure if this has unintended consequences, but adding a e.stopPropagation() at the end of the modal keydown handler, it seems to work to block the arrow keys from closing the modal while still a blocking Up/Down from closing the modal.

This works well for me!

At the same time, I'm wondering if turning the modal into a single (global) instance wouldn't fix and possibly prevent issues like this? We already control its visibility via a global state. We could also use openModal to pass extra props and maybe slotFill to control its content? Another advantage would be that we wouldn't need to import it every time we need to use it.

[jeryj]

@WunderBart Using a single global instance makes sense to me. That's a pattern I'm used to seeing. I assume this was considered when the component was being built, so it would be interesting to know the context of how the Modal was built.

[jeryj]

This would likely be fixed by #19879.

[afercia]

Maybe related: #18537 (for the modals part).

Also to verify if this happens only with Safari + VoiceOver.

[jeryj]

Maybe related: #18537 (for the modals part).

I bet that s related. Thanks for linking, @afercia.

Also to verify if this happens only with Safari + VoiceOver.

This instance will happen with or without VoiceOver. It seems to affect all browsers, even without a screen reader running.

[stokesman]

I just tried on trunk and can't reproduce this. I tried with both the iframed and non-iframed canvas. I don't know what changed but it seems focus does not escape the modal any more when using the arrow keys.

[jeryj]

Thanks for testing it again, @stokesman! I can't reproduce it either.