[Safari] Accent panel opened in a new line cannot be navigated

[f1ames]

Extracted from https://github.com/ckeditor/ckeditor5-typing/issues/95.

This issue have been extracted as it is somehow a recurring one. It looks like:

The last non-working version was v0.10.0 (however it behaved a little different there so the cause was probably different). When tested in v1.0.0-alpha.1 or v1.0.0-alpha.2 it works fine.

However, when tested on latest master (which will probably become a beta release soon) it looks broken (as shown in above gif). Looks like some changes in the meantime fixed it and then broke it again (will take a look with bisect later) 🤔

Anyway, from what I checked, the current cause is manipulating selection during composition (so we are back to #3742).

[f1ames]

After bisecting - breaking commit:
e866e4a -> ckeditor/ckeditor5-font@41e16e0

Really not sure what happened there, but previous commit works fine (or I missed something obvious) 🤔

[Reinmar]

The commit you found points to... a ticket in which we changed names of UI components and commands. So, we'd need to be very unlucky :D

[Reinmar]

I can reproduce this issue on dc6364d. Did you clear the cache when testing it?

[Reinmar]

It WFM on 764a765 and 12cc47a
It does not work on 222669b.

Which.. is very funny, because it's when we introduced CompositionObserver. Perhaps just plugging some listeners to composition events break it?

[f1ames]

The commit you found points to... a ticket in which we changed names of UI components and commands. So, we'd need to be very unlucky :D

Yeah, that was quite confusing :D But still, even when clearing history in Safari before every test (dev console opened), WFM in all three commits you pointed to. And stops working on commit I pointed to...

I do:

git checkout #hash
mgit update
npm run test:manual

[f1ames]

I have recently updated my macOS to High Sierra hoping maybe it will change something, but still it works as I described. Maybe this behaviour is influenced by some Safari/system settings.

Anyway, as mentioned in issue description it should be solved by #3742.

[f1ames]

I looked into this issue and there is a strange behaviour in Safari while navigating through accent panel. In Chrome characters are rendered when navigating through accent panel in a paragraph as shown below:

so it is just text updates and new accented character replaces the old one (as it is already replaced by the browser, renderer doesn't have to render anything - actions: [ "equal" ]).

And in Safari:

So for some strange reason, the br element is somehow reinserted. It looks more like Safari is inserting the br element and renderer rerenders it as block filler:

which basically breaks the composition. Looking at mutations seems to confirms it, first mutation which replaces a with <br> is fired and then another one which inserts ą (oldChildren is empty).

[f1ames]

Native mutations when long-pressing a in an empty paragraph and then pressing Arrow right 3 times:

Chrome

Safari

A lot more going on in Safari.

[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).