182132 - text positioned too high in cbc.ca dropdown menus

Status: RESOLVED INVALID

(Tech Evangelism Graveyard :: English Other, defect, P5)

Description

[HammerJoe]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021118
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021118

If you look under the big Marketplace picture there are four drop down menus and
the first two, Past programs and Marketplace files, the menu selections are not
displayed correctly overlapping each other.

Reproducible: Always

Steps to Reproduce:
1.load web page
2.Move your mouse under one of the selections : Past programs or Marketplace files
3.

Comment 1

[Faxmaster]

WFM:  using 2002112607 on Win2k.  What build are you using?

Comment 2

[HammerJoe]

I'm using 20021118.

This is insane to try to keep track of all the updates. :)

Comment 3

[R.K.Aa.]

WFM, trunk CVS, Linux.

Comment 4

[HammerJoe]

Attachment: Mozilla Bug

I downloaded latest build and this is what still happens.
Check the red menu and see the options not showing in the right place.

Comment 5

[R.K.Aa.]

WFM w/1.2 on WinXP as well.

Comment 6

[HammerJoe]

I just downloaded the 1.2 version and the problem still persists.
I'm surprised that it's working for other people.
To make sure we are all looking at the same thing, look at the attachment, do 
you see that red drop down menu?
Do you see how the dates are not spaced from each other equally? Do you notice 
how the date is over the separator???

Does this not happen to you??

Comment 7

[R.K.Aa.]

Attachment: screnshot of menu, Linux current trunk CVS

looked the same when i tested on 1.2 release on WinXP

Comment 8

[HammerJoe]

This is weird.

I have installed the latest version, didn't made any modifications I use the 
standard fonts with Winxp and I'm the only one with the problem??

Comment 9

[Chris Lyon]

WFM 20031024 on WinXP.

Reporter, can you still reproduce this problem with a new build?

Comment 10

[Chris Lyon]

HammerJoe, can you try again with Mozilla 1.3b?

Comment 11

[HammerJoe]

just finnished d/l 1.3b and no change, this problem is still there.

Comment 12

[HammerJoe]

It seems that I am the only one with this problem,, any ideas what might cause 
this so I can look on my system to see if I can correct it?

Thanks

Comment 13

[R.K.Aa.]

Have you tried deleting cache?

Comment 14

[Mikael Parknert]

Reporter, is this still a problem with 1.4rc3? Have you tried suggestions in
comment 13, or tried with a new profile

If not ok, then please comment again with details. 
If ok, then please resolve this bug as WORKSFORME. Thanks.

Comment 15

[Henrik Lynggaard Hansen]

I can confirm this bug, using the latest relaase version (1.4) on windows 2000.
I willl be attaching a screenshot to show the error. 

moving to layout for triage. I haven't been able to determine if this is a
mozilla bug, or a bug in the menu. 

Comment 16

[Henrik Lynggaard Hansen]

Attachment: Scrrenshot of the problem

Look at the screen shot, and you should notice that the text's in the menu
creeps upwards and into the seperator lines.

Comment 17

[Henrik Lynggaard Hansen]

forgot to reassign

Comment 18

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

I see the problem on Linux as well.

I strongly suspect it's a problem with the site (i.e., assuming the font will be
a certain height) rather than a Mozilla bug, so marking as P5 until someone
produces a simplified testcase.

Comment 19

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

Attachment: slightly simplified testcase

A bit more simplification is needed to see what's going on.

Comment 20

[Paul Melnikow]

Attachment: more simplified testcase

A much simplified, but still ugly test case.

This is a static page. The box on the left is using the HTML that ends up being
generated by the previously posted test case, and renders visually identical to
the leftmost popup menu.

The box on the right has 8 instances of <td align="left">&nbsp;</td> replaced
with <td align="left"> </td>, and presumably renders the way that the authors
intended.

The navigation menu is rendered by drawing a red box with a table of rollover
boxes and then drawing a table of links in the same location, so the problem is
that the cells in the first table are taller than the cells in the second
table. All of the cells are set to a height of 19px, but when the &nbsp; is
present, the cell renders at 20px instead.

Unless this &nbsp;-growing-the-box behavior is incorrect, this is just a
problem with the page (as suggested by #18), and not with Mozilla.

Comment 21

[Paul Melnikow]

Attachment: simple   example

This is a simple page that shows the behavior I've described. The three tables
have one cell each. The first has a space, the second has an  , and the
third has some text. The one with just a space renders at the specified height
of 15px; the others render taller.

Comment 22

[Paul Melnikow]

I think this bug should be closed.

The height of a cell containing only an   depends on the font size, is the
same as a cell containing text, and seems to be platform-dependent. (My first
example demonstrates the error on Windows, but both sets render the same on Mac
OS and Linux.)

For a cell containing nothing (or containing only whitespace), the font size
does not matter; the cell renders according to other factors (e.g. it's "height"
attribute).

The page originally reported here included sloppy markup for navigation menus
that relied on the fact that a set of cells with nbsp's would render at exactly
a certain height, when in fact, they rendered taller.

The problem is with the page. The only reason this would be a valid bug is if
the case from #21 is incorrect. I spent a while staring at this code (trying to
help get an ancient bug closed), and am happy to try to clarify or explain further.

Comment 23

[Pascal Chevrel (relman team) -> :pascalc]

invalid