Line break handling with smart quotes is incorrect
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
People
(Reporter: harris, Assigned: m_kato)
References
(Blocks 2 open bugs, Regression)
Details
(Keywords: regression)
Attachments
(5 files, 1 obsolete file)
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
Comment 1•1 year ago
|
||
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.
Comment 2•1 year ago
|
||
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?
Comment 3•1 year ago
|
||
(whoops, this updated testcase fixes my broken monospace-font styling in the previous attachment)
Comment 4•1 year ago
|
||
Comment 5•1 year ago
|
||
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?
Comment 6•1 year ago
|
||
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.
Comment 7•1 year ago
|
||
Thanks, let's call this a confirmed regression from bug 1719535 then, pending further investigation.
Comment 8•1 year ago
|
||
(And that means Firefox 122 is the first affected release, since this feature was preffed on for release users there in bug 1854032.)
Updated•1 year ago
|
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 9•1 year ago
|
||
Maybe, this is already fixed by ICU4X next version (https://github.com/unicode-org/icu4x/pull/4389)
Comment 10•1 year ago
•
|
||
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?
Assignee | ||
Comment 11•1 year ago
|
||
(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 between42,
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.
Updated•11 months ago
|
Updated•10 months ago
|
Comment 12•10 months ago
|
||
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?
Assignee | ||
Comment 13•10 months ago
|
||
(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.
Assignee | ||
Comment 14•10 months ago
|
||
Update line segmenter data file to match with Unicode 15.0.
Assignee | ||
Comment 16•10 months ago
|
||
Comment 17•10 months ago
|
||
Comment 19•10 months ago
|
||
Backed out for causing failures at line-breaking-013.html.
Backout link: https://hg.mozilla.org/integration/autoland/rev/ea031eb2c3e43e739089680dc40acc6c34d5b060
Failure log: https://treeherder.mozilla.org/logviewer?job_id=453472157&repo=autoland&lineNumber=7281
Comment 20•10 months ago
|
||
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.
Comment 22•10 months ago
|
||
Assignee | ||
Updated•10 months ago
|
Comment 23•10 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/fcc8ec2728b7
https://hg.mozilla.org/mozilla-central/rev/07bb40c2bb54
Updated•10 months ago
|
Comment 25•9 months ago
|
||
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.
Description
•