Use a fixed toolbar for the block toolbar in mobile

[youknowriad]

closes #18632
closes #14419

This is the nth attempt to use a fixed toolbar in mobile (See #18632 for the reasoning about why it could work this time).

We need to test this on real devices (which I don't have) and there's probably a bunch of issues I'm missing but on a small viewport on desktop this feels way better than what we had.

[jasmussen]

Thank you so much for exploring this. I strongly believe a top-docked toolbar is critical path important to ensuring that the mobile experience is good.

However unfortunately this branch doesn't address the fundamental issue as higlighted in the illustration in #7479 (comment). Here's a GIF:

You don't have to have a physical device to test, but you have to test it on the actual Mobile Safari for the unique quirks to show up. The way to debug is this:

• Install Xcode from the app store
• Then you can open Xcode > Open Developer Tool > Simulator

This opens up a simulated iOS environment, but it's actual iOS and actual Mobile Safari it runs. Better yet it integrates with MacOS, you can copy paste between your dev browser and the URL bar inside the ipad simulator, it’s even bridged so you can run localhost. You can also the Safari on the desktop to inspect inside mobile safari in the simulator. That way you can most literally inspect, tweak, change and test the markup realtime, on the iphone.

[youknowriad]

@jasmussen Do you know how technically we should solve the issue? Is it by applying "position: fixed"? Right now the header is "position: sticky" on mobile.

Also, if we do make it fixed and not sticky what do we do with the Admin toolbar (the black one), should we just hide it entirely?

[jasmussen]

To expand a little bit, for this to work, some things need to happen.

We need to change how the toolbar and general layout is created on iOS. This codepen shows something that gets us very close: https://codepen.io/joen/pen/yWWRrm

You can test this URL in Mobile Safari in the simulator: https://cdpn.io/joen/debug/yWWRrm/gareYzzyRqPr

Here's what that looks like:

What's going on here is:

• When the soft-keyboard shows up, the entire viewport gets pushed upwards. Which means if you have just fixed something to the top of the viewport, that gets pushed out of view.
• However it appears that you can have a fixed position element, in the case of the codepen example, a content div, that does resize, meaning the toolbar will show up even when the softkeyboard shows.

The problem that remains is that if you scroll to the bottom of the page, there's some whitespace there from the body element underneath the resized element that you can still scroll. So we likely need to apply a hack so you can't scroll the body element.

[jasmussen]

Also, if we do make it fixed and not sticky what do we do with the Admin toolbar (the black one), should we just hide it entirely?

There are a few options to explore here, provided we find a feasible approach. One is to make the block toolbar sticky as opposed to fixed, so you scroll past the adminbar before that, or we can some some fancy "scroll collapsing". This should be within reach. But I'm still curious whether we can stop the body from scrolling at all, and scrolling only the container, as shown in that codepen I linked.

[youknowriad]

To be fair, I think you're better positionned to fix this issue as you understand it better :) Do you think you could give it a try in this PR (as time allows). It should all be in one file editor-regions/style.scss

[jasmussen]

I'm not sure I have the skill to explore the ontouchstart hacks probably necessary to make this work.

Also CC: @frontdevde as I think he meant to look also.

[frontdevde]

Thanks for the ping, @jasmussen!

After creating #18632 yesterday, I started some more exploration into possible solutions for the remaining issues mentioned. I haven't found a satisfying solution yet though.

It's the end of the day for me over here and I'm out of office tomorrow but I'd be happy to continue looking into this next week if we're still in need of a solution.

[mapk]

What if we moved the toolbar to the bottom? Does that effect how Safari works with fixed areas on screen?

[jasmussen]

I'll give that a shot. But in the past we avoided that (fixed bottom) because that would also scroll out of view, and it would vary how much depending on soft keyboard height (zoom level, alternate keyboards, screen resolution).

[jasmussen]

By the way it's correct that the bugginess of Mobile Safari can only be experienced on a physical device or the simulator.

However the specific bugginess I explain in #18686 is only reproducible if you also toggle the soft keyboard, which changes the Mobile Safari behavior to be even more buggy:

[jasmussen]

@mapk I tried a bottom toolbar. Unfortunately it's a fair bit worse than the top-docked toolbar.

The trigger really is that the soft keyboard has to show up, this is what's causing the viewport issues with two scrolling containers and none of them sized correctly.

• When it's docked to the top, the toolbar starts out of view above the block. But it's accessible by swiping down just a little bit.
• When it's docked to the bottom, the toolbar starts out of view below the block, but you have to scroll way to the bottom for it to come into view.

The issue with being able to scroll the body element is present in both approaches, but is made worse in the bottom-docked version because it's more likely to trigger when trying to make the bottom-docked version show up.

[youknowriad]

Superseded by #18686