Mobile fixed toolbar: Scroll focused element into view

[frontdevde]

Description

This is a followup PR to #18686 which added a fixed toolbar to mobile.

This PR updates the hack we're using to make this work on mobile Safari (see #18632 for more context). With the hack, we reset the unwanted scroll that mobile Safari adds to the document when the soft keyboard is opened. This update now also scrolls the editor container by the value that mobile Safari tried to scroll the document. This way we achieve what mobile Safari was trying to do: scroll the element the user wants to interact with into view.

How has this been tested?

Tested in mobile Safari on a physical iPhone 11 with iOS 13.2.3 installed.

Screenshots

Before

After

Types of changes

Bug fix

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR. .

[jasmussen]

Thank you for keeping on this. Creating a usable mobile web experience is so key.

The difference in this PR to master is very subtle, blink and you'll miss it. But it seems to work well for me — which is impressive considering the state of Mobile Safari.

Here's the behavior in master:

Notice how when you click the bottom of a long paragraph, that bit gets covered by the soft keyboard so you have to swipe it into view to edit it.

This branch:

It's consistent most of the time: the place where you set the caret is what gets scrolled into view. It's not 100% solid, but it's much better than what we have today.

Code also looks well documented, simple, and iPhone specific.

[frontdevde]

It's consistent most of the time: the place where you set the caret is what gets scrolled into view. It's not 100% solid, but it's much better than what we have today.

@jasmussen This is due to a 100px threshold that you can find in the code. I probably should've added a comment around that. If the browser tried to scroll less than 100px we don't scroll the editor container. The reason being that otherwise unintentional scrolls on the toolbar could lead the document in the editor to scroll. The same goes for over scrolling. 100px seemed like the right point to draw the line where it worked consistently enough to create the wanted effect in the editor while eliminating most of the unwanted side effects. As you said, "it's much better than what we have today."