Autolink in Firefox places caret inside link

[Mark Wade]

Steps to reproduce

1. Using Firefox, go to a CKEditor build which has the autolink plugin present.
2. Paste a URL, for example ​https://www.google.co.uk
3. Hit space and continue typing

Expected result

The text you type appears after the link, not part of it (is behaviour in Safari and Chrome).

Actual result

The text you type is linked as if it was part of the URL.

Other details (browser, OS, CKEditor version, installed plugins)

Tested with:

• Firefox 43.0.2 (latest at time of creating ticket) on Mac OS X 10.11.2 (latest at time of creating ticket)
• CKEditor 4.5.6 (latest at time of creating ticket), Basic preset plus autolink plugin, Moono theme with English language

Effectively makes the autolink plugin unusable.

[Jakub Ś]

Problem can be reproduced from CKEditor 4.5 (when autolink was introduced) and is most likely related to #8195 (please also see ​https://dev.ckeditor.com/ticket/7796#comment:4)

[kkrzton]

There are few related issues: #7830, #8958, #10872, #11346, #12649. All are still valid at the moment. Probably the cause is not the same for all of them but some are surely connected so all of them should be taken into consideration when working on the solution.

[kkrzton]

This issue does not concern only autolink plugin but more general problem with handling links in FF (and differences in handling links in other browsers).

[kkrzton]

There are few additional related issues I found: #8149, #10709, #10966.

[kkrzton]

Run some tests how selection between different elements is handled inside contenteditable in different browsers.

It seems Chrome and IE are consistent (except #8149 for Chrome).

Firefox has like "stateful" selection. It means selected element depends on from which element cursor was moved or which element clicked. So in FF the selection for the same position depends on what user clicked or from what element moved the cursor. The exact same position can have to different selections/states. In other browsers same position always reports the same selection no matter what user did previously.

This behavior in FF is the cause of this and some of related issues.

​Test on jsfiddle.

[kkrzton]

Changes in ​t/14288.

The code also fixes #10709 for FF. IE needs to be handled separately (or probably may use same solution).

There is also an edge case caused by bogus <br>s mentioned here ​10966#comment:2, ​10966#comment:6.

[Jakub Ś]

Please have a look at #14563 as well. Besides typing, link dialog seems to be broken as well for links and BR's.

There is also another issue with continuing link to the second line with BRs - #14566.

[Tade0]

The fix looks solid - I think it's acceptable.

Additionally (for Firefox only obviously) it seems to solve #14563. Perhaps making this fix available for other browsers is worth considering?

Leaving as passed until it's clear whether we can also close #14563 as well.

[kkrzton]

@tade0 I checked this solution along with #14563 issue. After some small adjustments (listener priorities), this fix could be possibly used also for #14563 (ofc additional testing will be required for affected browsers).

If we would like to go this way I will suggest creating a parent ticket for those two issues so that we can have the code for both issues in a one place.

[Marek Lewandowski]

This issue is too risky to take it in upcoming minor release. Let's put it in our todo backlog.