Deal with not-yet-rendered scroll position changes in scrolling commands

[maxbrunsfeld]

Fixes #903

[maxbrunsfeld]

/cc @nathansobo @as-cii

In this command, we're trying to read the editor's current scroll position, and update it accordingly. The problem is that if we run this command rapidly (e.g. holding down ctrl-f), calls to TextEditorElement::getScrollTop() will not reflect the value that was previously set via ::setScrollTop(), because a DOM update hasn't happened yet.

Can you think of an easier way to do this? If not, maybe we need to add an API on TextEditorElement for accessing its current desired scroll position (i.e. the last value passed to ::setScrollTop).

[as-cii]

Thanks @maxbrunsfeld for bringing this up. So, there are a couple of ways in which we could solve this. We may either:

1. Add something like a TextEditorElement::getPendingScrollTop API;
2. Flush pending state (such as scroll positions) synchronously whenever methods like ::getScrollTop get called;

Personally, I would prefer 2) over 1) because it both feels more consistent with how the DOM works like and it doesn't expose an internal information which heavily depends on the update scheduling implementation. For example: what does pending mean here? In the current implementation we know that the scroll position's state is either pending or committed, but what if we started handling this differently by introducing a third state?

On the other hand, I understand the implications of having such a synchronous API: forcing reflows is not ideal, especially when the interaction with the user needs to happen repeatedly such as in this case (e.g. holding down a key). It's also true that people are already used to how the DOM behaves when reading/writing from/to it, so I feel like this wouldn't be a deal breaker. Indeed, this piece of code could be changed to make use of requestAnimationFrame (or our ViewRegistry::readDocument + ViewRegistry::updateDocument methods) to orchestrate DOM updates in a way that doesn't affect performance because of synchronous reflows.

What do you think?

[maxbrunsfeld]

Gonna 🚢 this as is for a quick fix, but hopefully we can come up with something cleaner.

[as-cii]

Thanks Max for addressing this, will take a better look at this tomorrow morning. 🙏