Closed Bug 628825 Opened 14 years ago Closed 8 months ago

Line breaking should not occur before punctuation, even when preceded by space


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




121 Branch
Tracking Status
firefox121 --- fixed


(Reporter: vincent-moz, Assigned: m_kato)


(Blocks 1 open bug, )


(Keywords: testcase)


(3 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-GB; rv: Gecko/20101203 Firefox/3.6.13
Build Identifier: 

Firefox currently allows line breaking before a punctuation mark when it is preceded by a breakable space, such as a thin space U+2009 (as used in French). This is incorrect. The line breaking algorithm should be improved, for instance as described by:

(Unicode Standard Annex #14 - Unicode Line Breaking Algorithm). In particular, see LB13: "Do not break before ‘]’ or ‘!’ or ‘;’ or ‘/’, even after spaces." Note that the list of cited characters is not exhaustive.

Reproducible: Always

Steps to Reproduce:
1. Open a page with a word followed by a thin space then by a punctuation mark such as "!" or "?" (see testcase).
2. Adjust the window width to see the various line breaking positions.
Actual Results:  
For some width, Firefox breaks the line before the punctuation mark.

Expected Results:  
Firefox should break the line before the word preceding it.

WebKit-based browsers have no such problem (tested only with a thin space).

The normal space should be handled as well, because some authors use it instead of a thin space (even with such a slightly incorrect typography, authors often don't use the typical no-break space, probably because a normal space is easier to type on a keyboard).
See also Bug 56652 and Bug 206152 with its Dependencies.
Keywords: testcase
Last I checked we purposefully allowed breaking before '/' because it's common for sites to depend on that.
How about the importance of this bug for Western language users? Is that a major format?
Version: unspecified → Trunk
Hmm, looks like the spaces are marked as breakable in nsLineBreaker::AppendText(). However, we need to access to nsILineBreaker's implementation when we check whether the next character is open punctuation or not...
s/open punctuation/close punctuation

Now, GetJISx4051Breaks() always returns FALSE for first character. It might be usable. If the first character is not breakable even with a breakable character, we can set TRUE. Then, nsLineBreaker can know the first character's class of "word" and it can overwrite the previous space's state. But this is just my guess.
Severity: normal → S3

As long as I test, this is already fixed by bug 1719535.

Closed: 9 months ago
Duplicate of bug: 1719535
Resolution: --- → DUPLICATE
Attached image screenshot

(In reply to Makoto Kato [:m_kato] from comment #8)

As long as I test, this is already fixed by bug 1719535.

In which FF version? According to bug 1719535, this seems to be fixed in 118, but with Firefox 118.0 under Linux, the bug still occurs. See attached screenshot for the testcase of this bug.

And I can still reproduce the bug with Nightly 120.0a1 (2023-10-01).

(In reply to Vincent Lefevre from comment #10)

And I can still reproduce the bug with Nightly 120.0a1 (2023-10-01).

Thank you for testing. OK, I will reopen this

No longer duplicate of bug: 1719535
Ever confirmed: true
Resolution: DUPLICATE → ---

data:text/html,<div style="width: 1px;">test&thinsp;!</div> seems to be simple test case. ICU4X can handle correctly, so this issue is layout side.

Legacy segmenter breaks line by some Break After properties. But UAX#14 rule
doesn't break Break After (BA) at force.

So I would like to remove some legacy rules that isn't ASCII white space from

Assignee: nobody → m_kato
Pushed by
Don't break line by Break After. r=TYLin,jfkthame
Created web-platform-tests PR for changes under testing/web-platform/tests
Closed: 9 months ago8 months ago
Resolution: --- → FIXED
Target Milestone: --- → 121 Branch
Upstream PR merged by moz-wptsync-bot
Duplicate of this bug: 1125644
You need to log in before you can comment on or make changes to this bug.