Closed Bug 1880362 Opened 8 months ago Closed 6 months ago

Line break handling with smart quotes is incorrect

Categories

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

Firefox 122
defect

Tracking

()

VERIFIED FIXED
126 Branch
Tracking Status
firefox-esr115 --- unaffected
firefox123 --- wontfix
firefox124 --- wontfix
firefox125 --- wontfix
firefox126 --- verified
firefox127 --- verified

People

(Reporter: harris, Assigned: m_kato)

References

(Blocks 2 open bugs, Regression)

Details

(Keywords: regression)

Attachments

(5 files, 1 obsolete file)

Attached image Untitled.jpg

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:122.0) Gecko/20100101 Firefox/122.0

Steps to reproduce:

On a website I'm drafting, the following string appears:

the NYPD was humiliated by the protests on January 8,” Dunlea said

The length of the column on desktop (macOS 14.1.1 (23B81), FF 122.0.1 (64-bit)) just so happens to cause the line break to fall after the comma, like so:

the NYPD was humiliated by the protests on January 8,
” Dunlea said

Typography rules dictate that the end quote should be kept on the same like as the word that precedes it and in fact using a "dumb" quote, the behavior is correct and it instead breaks:

the NYPD was humiliated by the protests on January
8," Dunlea said

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Layout: Text and Fonts
Product: Firefox → Core
Attached file testcase 1 (obsolete) —

Thanks for the bug report. I can reproduce -- here's a testcase. This seems to be specific to cases with a digit followed by a period followed by smart-quotes.

I think this might be related to TYLin's recent segmenter work - I recall there being different linebreaking opportunities when non-ASCII characters are involved in another bug he mentioned there...

TYLin, could you take a look when you're back from vacation?

Flags: needinfo?(aethanyc)
Attached file testcase 1

(whoops, this updated testcase fixes my broken monospace-font styling in the previous attachment)

Attachment #9380528 - Attachment is obsolete: true

Regression range for getting to our current behavior (in Nightly):
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=06273ebf279aad7827a5bd6c083dfb819eb55cb1&tochange=2f07664dbc304adeae1029ead0f4ab014aaa02a8

--> This is from enabling the icu4x segmenter in bug 1719535.

Makoto, maybe you could take a look and double-check if this new behavior is per-spec or not?

Severity: -- → S3
Flags: needinfo?(m_kato)

According to https://www.unicode.org/Public/UCD/latest/ucd/LineBreak.txt, both the ASCII double-quote U+0022 and the closing quote U+201D (and other related quote marks) have line-break class QU, which should prevent such a break (https://unicode.org/reports/tr14/#LB19). So the different behavior here seems surprising.

Thanks, let's call this a confirmed regression from bug 1719535 then, pending further investigation.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Regressed by: 1719535

(And that means Firefox 122 is the first affected release, since this feature was preffed on for release users there in bug 1854032.)

Assignee: nobody → m_kato
Flags: needinfo?(m_kato)

Maybe, this is already fixed by ICU4X next version (https://github.com/unicode-org/icu4x/pull/4389)

I have a similar problem here, first seen with Fx 123 on Android, but probably older:
https://olafschlindwein.de/
Works in Chromium and worked in Firefox before.

There are two blue HTML tables. On narrow screens unwanted line-breaks appear in the right cells.
Breaking eg between 42, and (–)
Is this the same Issue? Should I file a new bug?

Flags: needinfo?(m_kato)

(In reply to j.j. from comment #10)

I have a similar problem here, first seen with Fx 123 on Android, but probably older:
https://olafschlindwein.de/
Works in Chromium and worked in Firefox before.

There are two blue HTML tables. On narrow screens unwanted line-breaks appear in the right cells.
Breaking eg between 42, and (–)
Is this the same Issue? Should I file a new bug?

It will be also fixed by https://github.com/unicode-org/icu4x/pull/4389. After ICU4X 1.5 is released, we will upgrade it into Gecko.

Flags: needinfo?(m_kato)
Flags: needinfo?(aethanyc)

Doesn't seem like the 1.5 release is going to be happening any time soon. Can we cherry-pick the fix in the mean time?

Flags: needinfo?(m_kato)

(In reply to Ryan VanderMeulen [:RyanVM] from comment #12)

Doesn't seem like the 1.5 release is going to be happening any time soon. Can we cherry-pick the fix in the mean time?

I guess that we can fix this by updating toml file. I try it.

Flags: needinfo?(m_kato)

Update line segmenter data file to match with Unicode 15.0.

Duplicate of this bug: 1887392
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/45531 for changes under testing/web-platform/tests

These are "unexpected passes" in line-breaking-013.html and line-breaking-014.html, which apparently got fixed by the updated segmenter data, so we just need to remove the existing failure annotations.

Upstream PR was closed without merging
Flags: needinfo?(m_kato)
Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → 126 Branch
Upstream PR merged by moz-wptsync-bot
Flags: qe-verify+

Reproducible on a 2024-02-14 Nightly build on Windows 10.
Verified as fixed on Firefox Nightly 127.0a1 and Firefox 126.0b6 on Windows 10, macOS 12, Ubuntu 22.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: