1423408 - Allow line-break after … (ellipsis) when immediately followed by letter [was Rendering glitch on dcrainmaker front page]

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Eric Rescorla (:ekr)]

Attachment: Firefox

URL:
https://www.dcrainmaker.com/

See attached screenshots from Firefox and Chrome

Comment 1

[Eric Rescorla (:ekr)]

Attachment: Chrome

Comment 2

[Mike Taylor [:miketaylr]]

Karl, care to take a look?

Comment 3

[Eric Rescorla (:ekr)]

Note: this seems to happen with a narrow firefox window, but Chrome resizes properly and Firefox doe snot.

Comment 4

[Karl Dubost💡 :karlcow]

Attachment: firefox left, safari right

I know why it's happening I'm just now trying to make it clear.


Let's make a codepen.io
https://codepen.io/webcompat/pen/YEbLeg

The reason is that in

<h2><a href="https://www.dcrainmaker.com/2017/12/fitbit-rolls-out-slew-of-apps-to-ionicandummvirtual-cats.html">Fitbit rolls out slew of apps to Ionic…and…umm…virtual cats</a></h2>

you get this part "Ionic…and…umm…virtual" which for Firefox is one string, but for Safari is breakable. 

So the real issue is:

Is there a reason why "…" U+2026 (ELLIPSIS) is not a breakable character in Firefox.

Note that if we replace "…" by "." U+002E (FULL STOP) Safari would exhibit the same issue as it is a non breakable character (or whatever the correct term is).

Maybe Jonathan knows. Or at least where to move this if we think it's worth changing for webcompat.

Comment 5

[Jonathan Kew [:jfkthame]]

Our line-breaking code prohibits a line-break between U+2026 and a following letter, because U+2026 is assigned class 23 in intl/lwbrk/tools/jisx4051class.txt, corresponding to [d] in the table at https://searchfox.org/mozilla-central/rev/f5f1c3f294f89cfd242c3af9eb2c40d19d5e04e7/intl/lwbrk/nsJISx4051LineBreaker.cpp#152-177.

Changing the class of U+2026 to 2 (punctuation) would allow a break here. This leads to failure on an existing reftest (layout/reftests/line-breaking/leaders-1.html), which explicitly verifies that such a sequence does *not* break; but it's unclear to me whether there was really a strong basis for the existing behavior, or if we should simply change it for better webcompat (and IMO allowing break after ellipsis seems reasonable, in most cases) and update the testcase accordingly.

No other current tests are affected: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b0f67c639b63ab3e3b0b143cf282ad63e93b266e

:masayuki, I wonder if you have an opinion on this? Would allowing this break be acceptable, or do you know of any reason to reject it?

A further question: if we make this change, should we do the same for U+2024 and U+2025, the one-dot and two-dot leaders? Safari and Chrome allow breaks there as well, and they're part of a set of similar characters (U+2026 "ellipsis" could also be regarded as "three-dot leader"), though they're probably a lot less commonly used within text like this.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Although, I don't remember the exact reason why I wrote the testcase. But perhaps, I just followed the traditional behavior. So, perhaps, it's okay to change the behavior. As you say, perhaps, U+2024 and U+2025 are also treated as same class.

Perhaps, if it leads characters e.g., "…oh", we shouldn't break after them. So, perhaps, "2" is fine. When you write a patch, please add this case into the testcase.

Comment 7

[Jonathan Kew [:jfkthame]]

Attachment: Allow line-break between ellipsis/leader dots and a following letter

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 8935708 [details] [diff] [review]
Allow line-break between ellipsis/leader dots and a following letter

Thank you!

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/d1fd7e71f310
Allow line-break between ellipsis/leader dots and a following letter. r=masayuki

Comment 10

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/d1fd7e71f310

Comment 11

[Karl Dubost💡 :karlcow]

Attachment: dcrainmaker fixed

This is indeed fixed on the original site the bug it was reported. 
Thanks a lot everyone (for reporting, patching, reviewing).