propagate key down & press events upwards from NestedElementFieldView up to the top-level editor so key mappings work as expected

[twrichards]

https://trello.com/c/Z3K0WT7D/2160-fix-shortcuts-eg-cmd-z-not-working-in-key-takeaways-elements

It has been noticed that none of the key mappings (e.g. undo, redo etc.) have been working inside Key Takeaways. This makes sense since key-mappings are a plugin and we know from the exploration which led to #362 that events don't make it up to the top-level editor by default.

IMPORTANT: in #362 the click events were being forwarded up from ProseMirrorFieldView but doing the same for key events broke some tests for RTE, so moved the click event forwarding in #362 down to apply only to NestedElementFieldView

NOTE: the cypress test for undo/redo in the inner editors has been marked as 'skipped' since it wasn't working in CI (but was locally) and it has been manually tested - and we need to release this really.

What does this change?

This PR follows the pattern established in #362 to forward 'key down' events up to the top level editor so the key mapping plugin can do its thing. There is one notably exception the Enter key, as the line breaks were being misplaced.

How to test

Yalc it into composer local and add text in bursts, alternating between the outer editor and an inner editor (e.g. key takeaways) then Cmd-Z (to undo) a few times and see the undos applied in the correct order (unlike before).

How can we measure success?

Users experience is as before (muscle memory) is important here.

[twrichards]

@jonathonherbert can you think of any issues with this approach? and do you think we'd be better allow list the keys allowed to travel up to the outer editor

[rhystmills]

Working nicely in Composer when testing locally and not noticing anything misbehaving. Shortcut for other plugins (e.g. noting) are working, as are undo/redo and markup shortcuts (e.g. blockquote).

Seems to be an integration test failing but otherwise looks good.

[jonathonherbert]

@jonathonherbert can you think of any issues with this approach? and do you think we'd be better allow list the keys allowed to travel up to the outer editor

If everything's working as expected, this seems reasonable to me! I can't think of a problem with propagating keydown generally – I'd be interested to know more about the journey these events take from creation to model update w/in the context of contenteditable.

(My understanding is that edits to contenteditable fields are generally 'allowed' by Prosemirror, with some exceptions for browser-specific behaviour (where PM corrects after the fact). It's been a while since I looked at the code though.)

[davidfurey]

Are there any other events that we should forward while we are at it? https://github.com/ProseMirror/prosemirror-view/blob/5704aece3fd350f2ccfa04cfc7e861e9a38627c4/src/index.ts#L616

For example, do mobile keyboards send a keydown event or just a keypress event?

[twrichards]

Are there any other events that we should forward while we are at it? ProseMirror/prosemirror-view@5704aec/src/index.ts#L616

For example, do mobile keyboards send a keydown event or just a keypress event?

Good point @davidfurey - thank you. I've added in 95d0c05

[jonathonherbert]

Untested, but code LGTM, approving to unblock.