Cutting the widget scrolls editor to the end (with t/468)

[f1ames]

What is the purpose of this pull request?

Bug fix

Does your PR contain necessary tests?

All patches which change the editor code must include tests. You can always read more
on PR testing,
how to set the testing environment and
how to create tests
in the official CKEditor documentation.

This PR contains

• Unit tests
• Manual tests

What changes did you make?

Closes #1160.

[Comandeer]

Issue is still reproducible inside editor inside h1 tag after adding some more content (2-3 times more than now).

[Comandeer]

Can't these tests be moved to plugins/widget? They're widget specific, so that place seems more obvious to me. We got even plugins/widget/integration directory.

[f1ames]

👍 Moved to widget directory.

[f1ames]

The only way I was able to workaround this issue is to use the div element for blockless editor. Haven't found any negative side effects so it seems to be working fine.

The only problem is that for this 100ms (when pastebin container is present) we have invalid html structure (div inside h1).

I think the only reliable, not hacky solution would be get rid of pastebin as described in #1169.

[Comandeer]

Hmm, I have some doubts…

The biggest one is if we really want to merge this hack? Maybe we could (should?) just fix it in #1169?

The second issue is about produced markup. One of our defined editable elements is p. In terms of HTML putting div into p is not only disallowed, but even impossible as browsers parse <p><div></div></p> as <p></p><div></div>. However it seems that DOM doesn't have any issues with it 🤔

My proposal is to ditch this PR and work on #1169. WDYT @f1ames?

[mlewand]

Just to chime in, there's no chance in the world we'll be able to deliver #1169 in a reasonable time. If this PR does the job, let's just use it as a workaround, and then revisit this in future releases.

Just one more question: is this div in a p thing introduced by this very PR, or was it already in the editor since beginning?

[Comandeer]

Just one more question: is this div in a p thing introduced by this very PR, or was it already in the editor since beginning?

It seems to be there from beginning – that's how our fake selection works: putting hidden div at the end of the editable. It shouldn't work, but works flawlessly so far.

[mlewand]

So this is nothing critical that we need to fix ASAP in this release. Instead we'll deal with it in the upcoming.

Meanwhile to avoid UX regression for Edge users, let's use this PR as a temporary workaround. Feel free to add a reference in code comments to a #1169 saying that xyz could be safely removed when #1169 is fixed.

BTW:

It shouldn't work, but works flawlessly so far.

Love that part 😁