[WebKit][FF] Normalize behaviour of styles combo on link boundaries

[kkrzton]

While working on #14856 fix, we had a chance to look more in depth into how it works when applied on link boundaries (see also ​#14856#comment:12). The behaviour is quite inconsistent and should be normalized.

---

One important thing to mention is how browsers natively handle typing on link boundaries. Consider the following html:

<p><a href="#">Link^</a> text</p>

For WebKit browsers the selection is like in the above html, however, when you start typing it is moved outside the link (like <p><a href="#">Link</a>^ text</p>) so the typed text is not the part of the link. All non empty elements from within a link are copied (using styles combo creates empty element/s which are not copied in such cases).

In Firefox, the selection can be either <p><a href="#">Link^</a> text</p> or <p><a href="#">Link</a>^ text</p> and it behaves accordingly so the typed text becomes part of the link or plain text.

For IE/Edge browsers the selection always behaves and acts like <p><a href="#">Link</a>^ text</p>.

---

Now consider the resulting html after using styles combo on the following html:

Chrome

1.

<p>x<span style="font-size:12px"><em><a href="#">foo^</a></em></span>x</p>

After changing font size to 20px and typing bar becomes

<p>x<span style="font-size:12px"><em><a href="#">foo</a></em></span><span style="font-size:20px">bar</span>x</p>

2.

<p>x<a href="#"><span style="font-size:12px"><em>foo^</em></span></a>x</p>

After changing font size to 20px and typing bar becomes

<p>x<a href="#"><span style="font-size:12px"><em>foo</em></span></a>barx</p>

3a.

<p>x<span style="font-family:Georgia,serif"><a href="#"><span style="font-size:12px"><em>foo^</em></span></a></span>x</p>

After changing font size to 20px and typing bar becomes

<p>x<span style="font-family:Georgia,serif"><a href="#"><span style="font-size:12px"><em>foo</em></span></a>bar</span>x</p>

3b.

<p>x<span style="font-family:Georgia,serif"><a href="#"><span style="font-size:12px"><em>foo^</em></span></a></span>x</p>

After changing font family to Tahoma and typing bar becomes

<p>x<span style="font-family:Georgia,serif"><a href="#"><span style="font-size:12px"><em>foo</em></span></a></span><span style="font-family:Tahoma,Geneva,sans-serif">bar</span>x</p>

Firefox

1.

<p>x<span style="font-size:12px"><em><a href="#">foo^</a></em></span>x</p>

After changing font size to 20px and typing bar becomes

<p>x<span style="font-size:12px"><em><a href="#">foo</a></em></span><span style="font-size:20px">bar</span>x</p>

2.

<p>x<a href="#"><span style="font-size:12px"><em>foo^</em></span></a>x</p>

After changing font size to 20px and typing bar becomes

<p>x<a href="#"><span style="font-size:12px"><em>foo</em></span><span style="font-size:20px">bar</span></a>x</p>

3a.

<p>x<span style="font-family:Georgia,serif"><a href="#"><span style="font-size:12px"><em>foo^</em></span></a></span>x</p>

After changing font size to 20px and typing bar becomes

<p>x<span style="font-family:Georgia,serif"><a href="#"><span style="font-size:12px"><em>foo</em></span><span style="font-size:20px">bar</span></a></span>x</p>

3b.

<p>x<span style="font-family:Georgia,serif"><a href="#"><span style="font-size:12px"><em>foo^</em></span></a></span>x</p>

After changing font family to Tahoma and typing bar becomes

<p>x<span style="font-family:Georgia,serif"><a href="#"><span style="font-size:12px"><em>foo</em></span></a></span><span style="font-family:Tahoma,Geneva,sans-serif">bar</span>x</p>

---

While the elements order may be different I does not make any difference for visual appearance and CKEditor UI (<a><em>text^</em></a> and <em><a>text^</a></em> looks same and activates same states/controls in UI). This means for different elements order, the result of using styles combo should be the same in both appearance and UI state (same for one browser, not necessarily between browsers).

[Marek Lewandowski]

This is well known inconsistency between the browsers, but I can't find the ticket number. Pinged @j.swiderski for help.

[Marek Lewandowski]

Restored original description.

[Marek Lewandowski]

There were some discussions in the past regarding selection normalization problem: ​https://www.drupal.org/node/2671896, ​http://dev.ckeditor.com/ticket/14506.

The source of the problem is here: ​https://bugs.chromium.org/p/chromium/issues/detail?id=170203

But for now Blink team gives it won't fix.

[Jakub Ś]

Here are two more issues reported to browser vendors: ​​https://bugs.chromium.org/p/chromium/issues/detail?id=588418 and ​​https://bugs.webkit.org/show_bug.cgi?id=154496.

The bottom line is that this behaviour is controlled by the broswer itself and there is not much CKEditor can do about it. We have to wait for browser vendors to provide a fix.

[kkrzton]

Thanks for all references. Ok, I see that this behaviour cannot be normalized across browsers due to those native/vendor issues. However, this issue initially was about fixing the behaviour of styles combo when used with selection on link boundaries (and not necessarily across browsers - now I know why it cannot be done). I used Chrome and Firefox because those inconsistencies can be observed in those browsers (in each browser itself).

Still, the main point here is:

While the elements order may be different, it does not make any difference for visual appearance and CKEditor UI (<a><em>text^</em></a> and <em><a>text^</a></em> looks same and activates same states/controls in UI). This means for different elements order, the result of using styles combo should be the same in both appearance and UI state.

If the description is not clear enough, you may take a look at html code samples 1. and 2. for both Chrome and Firefox. You can see even though the visual and UI appearance/state are the same, the results are different.

If we do not plan to work on this one (it is kind of edge case), I am ok with closing it. If we would like to do something with it we should reopen this one or rephrase/split it and create new issue if this one is not clear enough / too general.

I am not sure if VendorFix CantFix status should be used. While this vendor issue can be observed in those cases also (in Chrome at least), it is not the case why it cannot be fixed nor the only reason this issue exists.

[Jakub Ś]

@k.krzton if you are convinced you can provide a fix for this issue, you are welcome to do so of course. Pull requests proving it can be done are more than welcome.

CKEditor UI (<a><em>text^{</em></a> and <em><a>text}</a></em> looks same and activates same states/controls in UI

While this case is ok, I would recomend thinking of other cases where this might not necessairly look the same, because as you will see in this ticket #5503 in many cases order does matter.