Have plugin handle scrollToSelection events when they occur within elements #397
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
co-authored-by: @rhystmills - who is responsible for anything untrue in the following PR description:
What does this change?
Currently, some inner editors (e.g. one of our text fields), hand responsibility for certain commands to the outer editor - notably the
nestedElementField
, which passes events to the outer editor so that it can handle undo, formatting, and other commands. As part of these commands, the outer editor callsscrollIntoView
- which has led to a bug.This behaviour hasn't caused problems until now - the only pre-existing fields that have formatting options have their own menu plugins (e.g. the caption in image elements), so don't need to hand control to the outer editor. There was a PR to specifically handle this problem for history, which did have a similar problem. The problem is also much more obvious in our list elements because they can potentially be very long, so skipping to the 'top' of the element is very jarring for users.
This PR marks
scrollIntoView
as being handled by theprosemirror-elements
plugin. We're not actually handling those events - we're just telling the outer editor that they're handled, then discarding them, so that the outer editor doesn't attempt to do so.We're keen to get this mitigation out quickly because the bug is degrading the experience significantly in our list formats.
It would be good, in the near future, to:
scrollToSelection
behaviour properly, i.e. making sure the specific field within thenestedElement
is scrolled to when a user makes changes - this will make it clearer what changes are being made when, e.g, a user uses undo or redo withinprosemirror-elements
. State changes to nodes are the only thing the inner editors see (i.e. they don't see transactions). We may want to set special markup on nodes that the inner editor can react to - we do something similar for selections at the moment.How to test
Use in Composer locally via
yalc
and test usual behaviour.