138934 - Text in <li> overlaps float

Status: RESOLVED WORKSFORME

(Core :: Layout: Floats, defect, P2)

Description

[Herbie Robinson]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1)
Gecko/20020417
BuildID:    2002041712

It would appear that the routine that computes how much space text is going to
take up is out of sync with the routine that renders text.  In particular, the
metric routine appears to be coming up with smaller widths than the actual
rendering.

Symptoms:
o Text runs with different atributes (underlining, bold, italics, etc) run into
each other at the transition points (http://komodo.mozilla.org/buster/).
o Text runs into other objects on the screen (resource:///res/samples/test6.html).
o The cursor gets out of sync with what you are typing in an input field.  The
form I'm filling in now is a good example.

Reproducible: Always
Steps to Reproduce:
1.  Display any of the pages mentioned above.   The nested table test is
especially good at showing this when you resize the window.
2.  This does not happen in the URL entry field, only in the content portion of
the window.
3.  I am using Adobe postcript fonts with a font manager (Font Reserve); so, the
font files are not on the system disk.

Actual Results:  Text overlaps with other things on the screen (including other
text).

Expected Results:  Text shouldn't overlap.

Potential causes of this are:

Computing metrics on a string of text, but rendering characters individually.

Not getting the parameters exactly the same when calling Apple's magic text
rendering and metrics routines.  It's been a year; so, I don't remember the
details, but I do remember they were quite complicated....

I'm pretty sure this is related to using Postscript fonts.  I just tried
Charcoal and everything worked fine.  I have tried a number of Postscript fonts
(Times, Poppl-Laudatio, Utopia, Helvetica, Russel Square) and they all mess up.
 It could also be the location or something else related to the font manager,
but it seems unlikely as I can select things fine.

This is on OS X 10.1.3

Comment 1

[Nick Kocharhook]

Although I can't see this on the komodo page mentioned by the reporter, I do see
this on other pages:

http://www.libpng.org/pub/mng/mngapps.html

OS X, build 041712 (rc1)

Comment 2

[Nick Kocharhook]

Changing the character coding on the MNG page to ISO-8895 fixes the overlapping
text issues.

Comment 3

[Kai Lahmann (is there, where MNG is)]

maybe a dup of bug 138742 ?

Herbie: can you test, if you have the same problem on http://advogato.org ?

Comment 4

[Boris Zbarsky [:bzbarsky]]

They are both likely dups of older bugs...

Comment 5

[Kai Lahmann (is there, where MNG is)]

CC coz this could get interesting (even as I nowhere see it)

Comment 6

[Herbie Robinson]

I appears to be very similar to 138742.  It, in fact, garbles just about
everything in sight.  That's why only only searched OS X bugs before
adding this one:  I assumed that if this was in all implementations that
it would have been fixed a long time ago.  Also, it looks like the kind
 of thing that could be OS dependent and it's the same bug in different
code.

I also made another discovery trying to reproduce this:

It doesn't happen for small font sizes!  With the "times" font, the
screen display is OK if the size is 14, but starts messing up when the
size is 15.

Even more curiously, I have just set the size to 14, and it is still
absolute  hell typing this comment into the form.  The cursor position
is still broken.

Ahh, that's because the monospace font is Courier.  Changing the size for
Courier from 13 to 12 fixed that problem.

Those sizes are in pixels, not points.  

Is it possible we are crossing the boundary were OS X does anti-aliasing (12
points, I think) and the metrics call is somehow either not being told exactly
the same thing as the rendering call OR maybe there is a Mac OS X bug in the
metrics call?

Comment 7

[Herbie Robinson]

I'm sure you know more about this than me, but I've used the Mac routines
MeasureJustified and DrawJustified and they do seem to work consistently if all
the parameters are the same...  Including both the numerator and denominator in
the scaling parameter.  I suspect it can't just be the same ratio, but has to be
the same numerator and denominator (as they probably compute the size using just
the numerator and then divide the total by the denominator when they are done).

Comment 8

[Chris Petersen]

Confirming issue in May 23 OS X build (2002-05-23-08). Probably related to bug
138742.

Comment 9

[Kevin McCluskey (gone)]

-> dcone

Comment 10

[Jonas Maebe]

I also see this on <A
HREF="http://www.macdevcenter.com/pub/a/mac/2002/10/22/macforunix.html">http://www.macdevcenter.com/pub/a/mac/2002/10/22/macforunix.html</a>
(not sure if it's exactly the same bug though). Scroll a bit down until you see
the gray box about the developer tools on the right, the text of the item next
to it runs through it. You may have to resize the browser window a bit to see
it. Running OS X 10.2.1, Mozilla build 2002101612.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Is this still an issue?

Comment 12

[Jonas Maebe]

Still occurs on the url that I previously mentioned (http://www.macdevcenter.com/pub/a/mac/
2002/10/22/macforunix.html, text runs through the gray text box next to point "3. Startup")

Comment 13

[Jonas Maebe]

Forgot to mention: that's under Camino 0.7 (release). It also still happens in Mozilla 1.3, but there 
the overlapping is much smaller (although it's still there).

Comment 14

[Boris Zbarsky [:bzbarsky]]

OK, I see the problem on that url.  A testcase would be great here (I tried
constructing a trivial one bottom up and it does not show the problem, so it'll
have to be done by reducing the site....)

Comment 15

[Eli Friedman]

Attachment: macdevcenter.com Testcase

Basically, the problem is that long words in lists don't avoid floats like, for
example, those in <p> tags. (Both cases are labeled and shown)

I believe this is different from the original bug, though, so I think this
should be closed.

Comment 16

[Mats Palmgren (inactive)]

Attachment: Testcase #2

Comment 17

[Alex Krupp]

A good example of this problem can be found at http://www.wikineur.org. The bullet points on the top half of the page display fine, but the bullet points on the bottom of the page overlap with the text. I asked about this in #mediawiki on freenode, and was told that it seems to be a variant of the "browser sees <li> with no text and panics on the CSS"

Comment 18

[Boris Zbarsky [:bzbarsky]]

No, that's not this bug (and in fact is the right layout, last I checked).

Comment 19

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

I don't see the problem; I think this was fixed long ago, possibly by bug 143162.