1164759 - title is not shortened properly when containing multi-byte characters

Status: RESOLVED DUPLICATE of bug 898984

(Core :: XUL, defect)

Description

[sam113101]

Attachment: Captura de pantalla de 2015-05-14 01:07:25.png

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150416103922

Steps to reproduce:

Go there: http://www.reddit.com/r/Random_Acts_Of_Pizza/comments/330cr6/request_

Comment 1

[sam113101]

Sorry, I tried to paste the original link (which contained weird characters) and it seems to have messed with firefox's post data, or maybe it's a bug or limitation in the bugzilla software.

Here's the entire post:

Go there: http://www.reddit.com/r/Random_Acts_Of_Pizza/comments/330cr6/
Resize the window so that the title has to be shortened.

The title is shortened improperly. First, the text does not reach the right end of the tab as it's supposed to. Second, it seems to me that firefox is trying to split a multi-byte character in half (which shows up as a rectangle with an hexadecimal number in it).

The text should reach the right end of the tab and there should be no weird rectangles. My hypothesis is that firefox is counting the number of *bytes* rather than the number of *unicode characters*, which gives the wrong result. I could be wrong.

Comment 2

[Mark Hammond [:markh] [:mhammond]]

I can reproduce this on Nightly.

Comment 3

[:Gijs (he/him)]

Boris, I recall that for bug 1104875 you had to fiddle to make this not happen. I presume we need similar fiddling in XUL layout so that the cropping works correctly instead of mashing the multibyte things? Don't know if it's harder here because we are also trying to fit a particular width...

Comment 4

[:Gijs (he/him)]

(also, I'm surprised this isn't a dupe but I can't find any...)

Comment 5

[Neil Deakin]

Looks like we need to handle the width differently in nsTextBoxFrame::CalculateTitleForWidth, which has a note to this effect just before the switch statement.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Yes, comment 5 is spot on.  Instead of passing single chars to AppUnitWidthOfString we should be checking for surrogates, then passing the entire surrogate pair in as needed.  As in, use the (char16_t*, length) overload of AppUnitWidthOfString.

Comment 7

[Neil Deakin]

Attachment: Something like the following

Will work on some tests.

Comment 8

[Boris Zbarsky [:bzbarsky]]

You probably need to check that the next code unit is the other half of the surrogate pair too.  consider CropRight when you have a high surrogate followed by a not-low-surrogate code unit.  In that case you don't really want to measure that not-low-surrogate code init together with the high surrogate.

Comment 10

[Neil Deakin]

Attachment: Updated patch

This was the latest patch I had written. It seems to work, but the test does not since it relies on there being some font with a mostly predictable size with the right characters in it being available on all platforms. I'm sure that can fixed somehow but I moved on to other things before investigating that.

Comment 11

[Boris Zbarsky [:bzbarsky]]

It might be worth adding some non-BMP characters to Ahem?

Comment 12

[arni2033]

Just in case: bug 898984 describes the same issue

Comment 15

[Xidorn Quan [:xidorn] UTC+10]

It seems to me this is indeed a duplicate of bug 898984.