New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 531409 link

Starred by 2 users

Issue metadata

Status: Fixed
Closed: Oct 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment

Word wrappping algorythm doesn't work correctly for number-minus

Reported by, Sep 14 2015

Issue description

UserAgent: Opera/9.80 (Windows NT 6.1; WOW64) Presto/2.12.388 Version/12.12

Example URL:

Steps to reproduce the problem:
1. In element type "Someone (2015-)".
2. Set width to just barely fit "Someone (2015".

What is the expected behavior?
It should be wrapped:
1. "Someone"
2. "(2015-)"

What went wrong?
It is wrapped:
1. "Someone (2015-"
2. ")"

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes 

Chrome version: 45.0.2454.85  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version:

Firefox always moves years to next line even if both are present (e.g. in "Someone (1950-2015)" it's either whole sentence in one line or whole "(1950-2015)" in second line).
Labels: Needs-Feedback
To further investigate the issue, can you provide a sample html file with above test case ?

Comment 2 by, Sep 18 2015

Labels: -Cr-Blink Cr-Blink-Layout

Comment 3 by, Sep 21 2015

Attached simple test file.

Contains a small script to gradually increase width of lists without using manual style adjustments.
1.3 KB View Download
Labels: -OS-Windows -Needs-Feedback OS-All M-47
Status: Untriaged
Able to reproduce the issue on MAC and Linux. This is a Non Regression issue seen from M30.
Screen Shot 2015-09-22 at 10.07.36 AM.png
1.2 MB View Download

Comment 5 by, Sep 25 2015

Labels: Needs-TestConfirmation
Status: Unconfirmed
Unable to reproduce in 45, 46, or 47 on windows or linux.
Could you please retest on the latest stable version?

Comment 6 by, Sep 26 2015

Nothing changed - problem still occurs.

Google Chrome: 45.0.2454.101 (Oficjalna wersja) m (32-bitowa)
Blink: 537.36 (@3b3c00f2d95c45cca18ab944acced413fb759311)
Windows 10 (same thing happened on Windows 7).
Labels: -Needs-TestConfirmation
Status: Untriaged
Using the html file provided in Comment was able to reproduce the issue on Windows 7/10, Mac and Ubuntu on Latest Stable# 45.0.2454.101 and Latest Canary# 47.0.2521.0. 

Changing the width to 112 or 203 reproduces the issue. Attaching a screen shot for further reference.

Removing the label Needs-TestConfirmation, please add if required.
Thank You.
84.4 KB View Download

Comment 8 by, Sep 30 2015

Status: Assigned
When you get a chance would you mind looking into this wrapping bug Koji?

Comment 9 by, Oct 1 2015
improved "do not break after" cases but it looks like it did not pay much attention to "do not break before".

What to do spec-wise is a bit gray, CSS does not define strict interoperability here at this moment.

UAX#14 has LB13:

Code points that belong to the 5 classes in LB13 are:

We probably want a little more break opportunity than UAX#14 defines for compatibility, interoperability, and long URLs. I'll also check other LBs in UAX#14 if there are any worth to include.
Project Member

Comment 10 by, Oct 1 2015

The following revision refers to this bug:

commit 40da64cedd00110bbfa39449ce72b777d930b001
Author: kojii <>
Date: Thu Oct 01 15:13:18 2015

Fix line break opportunities between HYPHEN-MINUS and closing punctuation

This patch fixes not to break between HYPHEN-MINUS and closing
punctuation characters by following UAX#14 LB13[1].

 * changed to allow break after it all the time.
 * fixed HYPHEN-MINUS + DIGIT/PERIOD not to break.

This leaves the break opportunities before closing punctuation
characters such as ")".

UAX#14 LB13[1] defines character classes not to break before. Adding
this rule matches the behavior for these characters to IE11.


BUG= 531409 

Review URL:

Cr-Commit-Position: refs/heads/master@{#351806}


Comment 11 by, Oct 14 2015

Status: Fixed

Sign in to add a comment