218791 - bug - fast text calculation and word separation and wrapping are in contradiction

Status: NEW

(Core :: Layout, defect)

Description

[Sergei Dolgov]

Tested on Mozilla 1.5b release under BeOS and Windows 98.
Screenshot of problem
http://beos.spb.ru/fyysik/MozBug1.5.b-Nonwarpping1.png
Look at selected string. Two words are separated by '/'.
Mozilla seems counting it as single unwrappable word, while column widht
calcualted with those fast methods like nsRenderingContxt*:GetTextDimension()
uses average width calculation with probably mistaken break-point.
Problem don't happen if mozilla window size width  is at least about 800 pixels
in this case, but i think it may happen if we meet longer word pair

Comment 1

[Sergei Dolgov]

Attachment: screenshot

added screenshoot of problematic layout rendering as attachment

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

> Mozilla seems counting it as single unwrappable word, while column widht
> calcualted with those fast methods like nsRenderingContxt*:GetTextDimension()
> uses average width calculation with probably mistaken break-point.

I don't understand what you're trying to say here.

Isn't this just a duplicate of bug 218580?

Comment 3

[Boris Zbarsky [:bzbarsky]]

More or less, but we should not be having table cells overflow like that either,
unless the table is fixed-layout...  On the other hand, the URL in the URL field
does not match the screenshot.  What's up there?

Comment 4

[Sergei Dolgov]

I tried to say that that slash seems treated in two different ways - as word
separator when calculating text dimensions, and as letter when rendering text on
screen

Comment 5

[Boris Zbarsky [:bzbarsky]]

Sergei, is the slash thing BeOS-only?  Could you possibly attach a testcase to
this bug?

Comment 6

[Sergei Dolgov]

Boris, probably i should try to create testcase manually, but IIRC i noticed similar problem with "-" char - when text is non-"latin".

I'm wondering if "/" and "-" symbols are same for ASCII-7 and for other codepages, incl. non-western languages in Unicode, especially if content of sites
 is typed in MS Word and then copy-pasted:)

If not, parser/layout engine may work with bugs in such cases.

Comment 7

[Sergei Dolgov]

Reproduced under Windows XP:
Mozilla 1.7.12
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/2005091
http://beos.spb.ru/mozilla/mozilla_justify_bug_WinXP.png

Comment 8

[Sergei Dolgov]

Bug exists also in nightly trunk of SeaMonkey, e.g.
in Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.9a1) Gecko/20060201 SeaMonkey/1.5a

Comment 9

[Sergei Dolgov]

Attachment: testcase

problem looks to be dependent on padding style tag
style="padding: 1.2em 7% 0pt;"

Comment 10

[Boris Zbarsky [:bzbarsky]]

> I'm wondering if "/" and "-" symbols are same for ASCII-7

Doesn't matter -- by the time the parser or layout sees the text it's in UTF16.

> problem looks to be dependent on padding style tag

I'm pretty sure we have bugs on this...

Comment 11

[Sergei Dolgov]

Yes, as you see from testcase, bug affects also pure latin text.

Btw, i have report about another bug with padding, measured in "em" values, when page layout looks different in Windows and BeOS version of Mozilla.
Will try to find it out.

Wondering if parameters in nsLookAndFeel have some effect on those issues

Comment 12

[Sergei Dolgov]

seems multiplatfrom - changing OS

Comment 13

[Boris Zbarsky [:bzbarsky]]

Is this still an issue with our new word-wrapping setup post-reflow-branch?

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm not sure what this bug is about.