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

added screenshoot of problematic layout rendering as attachment

> 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?

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?

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

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

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.

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

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

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

> 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...

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

seems multiplatfrom - changing OS

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

I'm not sure what this bug is about.