[iOS] Sticky toolbar disappears after scrolling editor on iPad

[Mgsy]

Is this a bug report or feature request? (choose one)

🐞 Bug report

💻 Version of CKEditor

11.0.1

📋 Steps to reproduce

1. Switch your iPad's orientation to the landscape.
2. Open the classic editor with some scrollable content.
3. Put the selection in the first block.
4. Scroll down the editor a bit.

✅ Expected result

The sticky toolbar is visible.

❎ Actual result

The sticky toolbar doesn't show up.

📃 Other details that might be useful

It works fine when iPad's orientation is portrait.

[ma2ciek]

Possibly connected to the https://github.com/ckeditor/ckeditor5-ui/issues/405.

[Reinmar]

That's caused by the issues described in ckeditor/ckeditor5-design#149 – it's Safari's quirky viewport mechanics.

[oleq]

Exactly. I was thinking recently that maybe we should disable the stickiness in iOS. The toolbar would be static but predictable. What we have now definitely looks like a bug to the users.

[Reinmar]

That's an interesting idea. It would be irritating if you edit a long content, then you'd have to jump up all the time. But it'd indeed help in case of shorter texts.

[ItsNoHax]

@Reinmar I'm having this annoying behaviour. Related to iOS's viewport I assume

[Reinmar]

That's a combination of two problems – https://bugs.webkit.org/show_bug.cgi?id=191204 and an issue that I've been recently discussing on W3C TPAC which is a general lack of control over the native UI which, in this crowded space, makes it rather impossible to create your own UI in a reliable way. For instance, the fact that the caret ends below the toolbar, even though it's generally caused by the viewport issues, shows also our lack of ability to tell the browser where it should not position the selection on the screen or vice versa – where we should not position our UI.

IDK if you consider this a viable solution but not using the sticky toolbar would help now. You could use the decoupled editor and control the toolbar yourself. Perhaps, you'd be able to come up with a better location or placing logic for it.

[oleq]

I created a PoC of a solution to address this issue. The code is in https://github.com/ckeditor/ckeditor5/compare/ck/1280-sticky-toolbar-visual-viewport?expand=1.

• The good news is that finally this is fixable 🎉
• The bad news is that the window.visualViewport updates on iOS after the scrolling stops. And that means the toolbar has a wrong position for a (sometimes long) while and there's no workaround for that. But the position is corrected when everything finally stops (see the video below).
  • We could hide the toolbar when the scrolling starts and show it again when it stops. But I'd restrict this one to touch screens only.

RPReplay_Final1664547784.MP4

• There's another bad news: the config.toolbar.viewportTopOffset configuration that we have may not make much sense when the visual viewport kicks in (see the video). This config option works fine when there's an element on a web page with position: fixed that we don't want to cover with editor toolbar. But when the visual viewport is engaged for real, things with position: fixed are suffering from the same problem our toolbar used to suffer before this PoC: they go off screen. The editor remembers the configuration, though and wants to keep a distance to a no longer visible element. I'm not sure how do we address this one. On one hand, this config no longer makes sense in this case. On the other hand, developers could work around this one just like I did in this PoC (and keep fixed things fixed) and the config will make sense again.

RPReplay_Final1664548363.MP4

• I didn't test it on Android.
  • I tested it on Chrome (desktop), though. Instead of using a regular zoom (Cmd + +), you can pinching the touchpad to trigger the visual viewport. And that revealed some bugs because the toolbar stopped aligning with the viewport. This could be related to the quirks described here: https://bokand.github.io/viewport/index.html

[CKEditorBot]

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

[CKEditorBot]

We've closed your issue due to inactivity over the last year. We understand that the issue may still be relevant. If so, feel free to open a new one (and link this issue to it).