Closed Bug 1748061 Opened 3 years ago Closed 3 years ago

Firefox and Chrome have different behavior for line breaks in tables

Categories

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

Desktop
Windows 10
defect

Tracking

()

RESOLVED FIXED
98 Branch
Tracking Status
firefox97 --- wontfix
firefox98 --- fixed

People

(Reporter: alice0775, Assigned: jfkthame)

References

Details

(Keywords: nightly-community, parity-chrome)

Attachments

(3 files)

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.

Attached file reduced.html

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.

Flags: needinfo?(emcdonough)

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.

Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Pushed by jkew@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d4da64bb37b6
Make line-breaking behavior of fullwidth compatibility characters more compatible with UAX#14 and other browsers. r=platform-i18n-reviewers,gregtatum
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 98 Branch
See Also: → 1595428
Flags: in-testsuite+
Flags: needinfo?(emcdonough)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: