23770 - "Download Mozilla" area on http://www.mozilla.org is black, not white

Status: VERIFIED WORKSFORME

(Core :: Layout: Tables, defect, P3)

Description

[(not reading, please use [e-mail] instead)]

load http://www.mozilla.org on 4.x, and the "Download Mozilla" area on the
bottom right of the page has a white background.

load http://www.mozilla.org on 5.0, and the "Download Mozilla" area on the
bottom right of the page has a black background.

Comment 1

[Dawn Endico]

the entire box with all the text in it is black? It works ok for me on
yesterday's build. Its printing black on black?

Comment 2

[(not reading, please use [e-mail] instead)]

the entire box is black on black, except for links.

this is with my own build from this morning.

screenshot coming shortly.

Comment 3

[(not reading, please use [e-mail] instead)]

rats!  now it is black on white.

marking invalid.

Comment 4

[Dawn Endico]

I just saw this too. The first time I ran mozilla after today's compile,
the "Mozilla News" background was black. All that showed were the blue
links.Going to another page and hitting the back button fixed the problem.
Restarting the browser a couple times didn't reproduce the problem. I'm
not sure how. IIRC, I had a layout bug once that only manifested itself
the first time I ran the browser after a compile. Maybe this is one.

Comment 5

[Mats Palmgren (inactive)]

*** Bug 24208 has been marked as a duplicate of this bug. ***

Comment 6

[Dawn Endico]

This has happened to me many times since jan 12, although for me
its usually its the "mozilla news" table that has the problem. The second
row containing the news items (not the top row containing the words
"mozilla news") has the background set to black until the page is reloaded.
I've only noticed this happen when first starting mozilla and www.mozilla.org
comes up as the start page.

Assigning to HTML Tables component and clearing "invalid" resolution.

Comment 7

[Dawn Endico]

manually assigning to karnaze and marking chrisd as qa contact since
changing the component didn't do this.

Comment 8

[thue]

*** Bug 25916 has been marked as a duplicate of this bug. ***

Comment 9

[thue]

Note that, as describet in Bug 25916, I can just keep reloading until the
problem appears (at least on slashdot.org).

Comment 10

[Joseph Elwell]

Attachment: screenshot of the problem at www.slashdot.org

Comment 11

[Joseph Elwell]

I can verify that I've seen this on fresh installs of both WinNT and Linux M13 
builds. At both www.mozilla.org and www.slashdot.org as well as other web sites 
with tables.

Comment 12

[Dawn Endico]

jewell, and others... What speed internet connection do you have?
I was thinking that this may be another slow link table reflow 
problem.

The mozilla.org tables that show the problem are composed of tables
with a black background that contain tables with a white background.
(this is how the black bar effect is achieved). It looks like when
this bug happens that the information for the white background in
one of the table cells is lost so the black background bleeds through.

I'm pretty sure that slashdot also uses a black background overlaid
with a white backgrounded table. I wonder if other sites that exhibit
this problem do as well.  Perhaps some enterprising testcase writer 
can take a shot at this.

Comment 13

[Joseph Elwell]

I run WinNT from work on what I believe to be at least a t3. I can download 
mozilla from ftp.mozilla.org at 140K/sec. I run Linux at home on a cable modem. 
I'm afraid that client speed might not be an issue. Although, maybe when I load 
the pages the servers are responding slow.

Comment 14

[Gervase Markham [:gerv]]

I cannot reproduce this on my LAN connection using M13. Shift-Reloading lots of 
times didn't help.

I would like to attempt a testcase, but I'd be doing so blind. Also, if it's a 
speed issue, it probably wouldn't be seen on a small testcase...

However, just this morning, for the first time, I did see a similar bug on 
Navigator 2.0 on Windows 3.1. So, if you guys would care to fish out the 
codebase, track that down and send me a patch, I'd be very grateful...

Gerv

Comment 15

[Kevin Puetz]

I have seen this as well on slashdot and (far more rarely) other sites in M13.I
haven't seen it yet in the post M13 nightly's I've run, but I haven't spent as
much time in them yet...

M13, Linux/PowerPC (debian potato). Ethernet LAN, dual-T3 to the outside world
Usually extremely fast, though slashdot itself isn't always quick. Releading
will eventually resolve the problem, though not always on the first try...

Comment 16

[karnaze (gone)]

I can't reproduce it.

Comment 17

[Joseph Elwell]

just as a note, I haven't seen this in a while. I'm currently using 2000031708
winNT build.

Comment 18

["Zow"]

I also have not seen this at all in M14. It was so prevalent in M12 & M13 that

they were unusable for me (okay, maybe I rely on /. too much for my news). But

M14 is back to being my default browser. It would probably be instructive to see

what changes were made between M13 & M14 that could have fixed this, but as far

as I'm concerned, it's resolved.

Comment 19

[Gervase Markham [:gerv]]

I haven't seen it for a while either. Marking WORKSFORME - if anyone sees it 
again, feel free to reopen :-)

Gerv

Comment 20

[John Unruh]

Verified worksforme.