Try mobile toolbar below the block

[jasmussen]

This is very much an experiment, intended to help solve problems discovered in #6307 (comment).

Basically, on iOS you won't have access to the block toolbar until you scroll way up to the top. And if we dock the toolbar to the top of the block, it will be covered by cut/copy/paste. This PR moves the toolbar below the block instead, mitigating that.

GIF:

Note that we probably want to also disable entirely the isTyping feature which hides the block UI when you're typing. It is too hard to get back on mobile, and isn't helping much there anyway. Riad is it hard to disable isTyping only on mobile? Would appreciate help here.

[jasmussen]

Note that the huge amount of space below the block you're editing, that's because the viewport height doesn't change on iOS when the soft keyboard is showing.

[youknowriad]

Is the idea to keep the per-block toolbar on mobile and show it at the bottom (typing or not)?

[jasmussen]

Is the idea to keep the per-block toolbar on mobile and show it at the bottom (typing or not)?

Basically. With potential future enhancements, sure — but given the complexity of dealing with mobile safari's idiosynchracies, this seems the best approach for now.

[karmatosed]

I'm a little torn on this. On one hand yes it does solve issues but it creates a really cluttered visual experience and one I think it's easy to go wrong using. In saying that it's not super helpful as doesn't offer a solution as much as a feeling this needs iteration.

[jasmussen]

It's definitely not ideal. There's a lot of UI going on. Perhaps a redesigned mobile toolbar is necessary, so it's a single toolbar instead of one for the mover/trash, and one for the formatting.

However it solves an issue right now, which is that you can't use formatting on mobile at all.

I say that acknowledging that you were right to reverse the toolbar behavior, so the block toolbar is block-docked. In other words, #6307 (comment) did not solve our issues which was my error.

But the question is — should we fix this PR up so the mobile experience is usable, and then polish? Or should we tweak the toolbar on mobile first?

[karmatosed]

But the question is — should we fix this PR up so the mobile experience is usable, and then polish? Or should we tweak the toolbar on mobile first?

I feel make it usable but pretty rapidly lets move into the toolbar adjusting so it works properly on mobile. My concern is iteration doesn't happen, which is a concern we can mitigate with an issue kicking that off.

[tofumatt]

Drive-by comment from a new member of the team, sorry! 😅

Docking the toolbar to the top means less visual clutter and a more consistent place for it… and the cut/copy/paste modal that appears is only temporary. Once the user has selected their text/copy+pasted it goes away, so the cut/copy/paste popup temporarily obscuring the toolbar seems better than docking it to the bottom… especially as there is a tiny gap between it and the keyboard that way, which seems like wasted space (especially on a small screen).

Aside from usual mobile text selection popups, what's wrong with always docking it to the top of the screen?

EDIT: Oh wait, I saw: #6307 (comment), and I get the issue now.

[jasmussen]

Docking the toolbar to the top means less visual clutter and a more consistent place for it…

Yep, that was the reason why we started with this design. However as discovered in #6307 (comment), the way iOS safari handles text input means this is very very very difficult.

Ah, I see you sneakily edited :D :D glad you picked up the challenge.

Once the user has selected their text/copy+pasted it goes away

Yeah except if you want to make something bold, you have to select it first — and that invokes the bubble! Tricky. If it were a native app we could be smarter about it.

[tofumatt]

If it were a native app we could be smarter about it.

Yeah, I noticed in the actual WordPress app that certain text fields near the top put the pop-over under the text rather than over it. (I wonder if there's some weird WebKit attribute we can use to control that?) 🤷‍♂️

[jasmussen]

I spent a good deal of time investigating, and there are a few ways to workaround the Safari quirks, but it's super duper hacky, very complex, and something that takes time to do. That doesn't mean we shouldn't do it, but it means we need an interim solution.

To try and put it as simply as possible — on Android, when the soft keyboard is showing, the viewport is resized. So for example if it starts out at 480x800 (I know, archaic resolution, using as example), then it is resized to 800 minus the keyboard height when that's open, for example 480x400px. This is cool because you can still use fixed position to dock things to the top or even bottom of the screen, like toolbars.

On iOS Safari, things are different. When the soft keyboard is showing, the viewport is not resized, it's just pushed upwards the height of the keyboard. That means if you have something that's aligned to the top of the viewport, it's now out of view. Not only that, but when the soft keyboard is showing, position: fixed; stops working. It's kind of nightmarish.

The hacks I'm referring to involve detecting when the soft keyboard is showing (keyboard heights vary depending on iPhone and which keyboard you have installed), and then setting a fixed height on the html element so that it's the same size as the available screen minus the keyboard. You'd think that was enough, but no — because we can't resize the viewport, we can only resize the content. "That's cool, I'll just apply overflow: auto; and -webkit-overflow-scrolling: touch; on a child element and use flexbox to emulate a fixed position header!", you might think. And sure, that works, until you scroll to the end of the content, and you start scrolling the HTML element again, because on iOS, overflow: hidden; does nothing on either the html or the body elements. Which means if you want to get this hack to work, you have to intercept the touchstart and touchend events, block them, and then basically rebuild them yourself.

┻━┻ ︵ヽ(`Д´)ﾉ︵ ┻━┻

iOS safari is a nightmare hellride.

So far, the only web-app editor I've found, that's not an actual app, that has done mobile editing on iOS decently, is Notion. They actually do both the viewport hack, and the below-the-caret toolbar. It's working pretty well, I recommend giving it a spin.

[karmatosed]

I think we need to make an issue to move onto next step after this, but it's a good progress forward.

[jasmussen]

Should we merge this as is and iterate? It solves an issue with typing on iPhone, even if not in an ideal way.

[jasmussen]

Merging this in, because:

• it fixes an issue with iPhone
• is simple css only and easy to revert
• it's one step on a path to more mobile improvements
• it's been both approved, and sitting in a branch for a long time