Steps to reproduce:

1. Open http://www2.city.neyagawa.osaka.jp/school/e/chuo/blog.html
2. Scroll and observe table 日課時限表

Actual results:
Because some text is not line breaking, the right side of the table has been cut off.

Expected results:
The table should be shown without cut off.

It seems to be caused by Chrome's misinterpretation of FULLWIDTH TILDE (U+FF5E) and WAVE DASH (U+301C).

The severity field is not set for this bug.
:alaskanemily, could you have a look please?

For more information, please visit auto_nag documentation.

So the real difference here is that Firefox doesn't allow a line-break between digits and the FULLWIDTH TILDE (U+FF5E), while Chrome does. So in Firefox, those table cells with content of the form <time><tilde><time> don't wrap unless there's a space on one or other side of the tilde, whereas in Chrome they are all happy to wrap even without spaces.

Minimal example:

data:text/html,<div style="width:min-content">8:35&%23xff5e;8:45</div>

This renders as

8:35～8:45

in Firefox, and as

8:35
～
8:45

in Chrome.

Note that if we use an ASCII tilde instead of the fullwidth compatibility character, neither browser will line-break there.

Currently we treat most of the "fullwidth" characters equivalently to their ASCII counterparts. However, I notice that Unicode's LineBreak.txt disagrees with this, classifying many of them (including alphanumerics, as well as various punctuation) as ID which means they would allow breaks.

I expect, therefore, that the new Segmenter implementation will -- unless we explicitly take steps to avoid it and maintain existing behavior -- bring us more in line with Blink here. This will change behavior for some content, and probably break some existing tests, but perhaps the overall result will be better; certainly more interoperable.

I experimented with this, and it turns out that some minor tweaking of the existing line-breaker properties for the fullwidth compatibility block, so as to more closely follow UAX#14 and the other browsers, doesn't appear to disrupt any of our legacy reftests, and makes us start passing a bunch of WPT testcases that currently fail.

So I propose that we go ahead and make a change here, which will resolve the interop problem reported, even though we're expecting to replace the line-breaker completely in the near future. Patching the existing code allows us to fix this right away, and means that when the new implementation lands, the amount of behavior change it introduces will be reduced as this change will already have happened.

https://treeherder.mozilla.org/jobs?repo=try&revision=2f70ea95ab8667c6de2258e1e783bf2173d85c2e

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