210156 - CSS background colors lost in padding when multiple javascript files are loaded in page body [Sides of Netflix borders not displayed on reflow]

Status: RESOLVED DUPLICATE of bug 244017

(Core :: Web Painting, defect, P2)

Description

[Sean Kane]

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

I am able to reproduce this bug on all versions and platforms of Mozilla that I
try.  It is complicated, and I will try to describe it the best I can.

Page details:
Page background set to gray.

Parent DIV aligned center sets background color to white, left and right margins
to black, and sets padding of 20px.

Child DIV #1 floats right and is approximately 200px wide. 
Child DIV #2 floats left and is approximately 500px wide.
Child DIVS 1 and 2 are siblings.
Child DIV #3, another sibling has a style clear:both.
the parent div is closed.

Within DIV #2, two javascript files are loaded, both about 10k in size or more.
 Each javascript file contains document.write information.

Javascript #1 is called, and its function that returns the document.write
functionality is called several times.

Javascript #2 is called, and and the functions that return the document.write
functionality for both javascript #1 and #2 are called several times.


On page refresh, the padding on both the right and left side of the frame (the
padding being set by the parent DIV) is shown as gray, not white.  When
scrolling the browser down one screen, then scrolling it back up, the display
corrects itself.

When moving one of the two javascript calls above the parent div, the display
corrects itself.

This happens every time on a hard refresh.  And occasionally with a cached page
load.

This does not happen on netscape 6.x or 7.x or any other browser than all
platforms and versions of mozilla I have tried.

Reproducible: Always

Steps to Reproduce:
See above details
Actual Results:  
See above details

Expected Results:  
See above details

Comment 1

[Bill Mason]

I think it's safe to assume we're going to need a minimized testcase for it.

Comment 2

[Sean Kane]

Attachment: Example of the problem mentioned.

This has been consistently reproducing the bug, esp. on refresh.

Comment 3

[Mats Palmgren (inactive)]

WFM, 2003-06-20-08 trunk Linux.  I see the effect while the page loads but it
always looks OK when the page is fully loaded.

Comment 4

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

confirming.

Comment 5

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

I see this on win2k, on my mozilla 1.4 branch build.

screen shot coming

Comment 6

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

Attachment: screen shot (top is before a repaint, bottom is after)

Comment 7

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

Is this Windows-only?

Comment 8

[Sean Kane]

I also get the same behavior on Mac osX

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3.1) Gecko/20030425

Comment 9

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

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

Comment 10

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: New minimalized testcase.

Comment 11

[Bjarne D Mathiesen]

it's a css-error:
the stylesheet puts the contents in two div's that are both floated.
thus the div with the border definitions gets it's height reduced to only
showing what's above the two floated div's

Also the whole testcase is a complete mess with invalid nesting of tags, tags
that aren't closed, duplicate opening of tables, incorrect values for parameters
etc etc

Mozilla is doing the right thing
The page coder is at fault

recommending resolving as invalid

Comment 12

[Bjarne D Mathiesen]

Stepen asked me to post the css/html solution to the problem.
This article <http://www.webmasterworld.com/forum83/1725.htm> explains the
issues completely and exhaustively

Comment 13

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

That article requires registration, so it's hard for me to tell whether I like
the advice it's giving.  The pure CSS solution that only works on a few browsers
is to use

...whatever...:after { display: block; clear: both; }

although I'm not even 100% sure that it works for us (though it should, per the
revised CSS2.1).

The more reliable workaround is to simulate that :after content with a div as
the last child.

Comment 14

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

resolving INVALID. thanks guys. If you want to reopen and assign to evangelism,
feel free.

Comment 15

[Stephen Donner [:stephend] Not actively reading bugmail]

Sorry, after further thought and some preliminary discussion with bz, I'm going
to reopen this, just for further hashing-out.

On their member page, http://www.netflix.com/Default, I'm seeing inconsistent
behavior with our rendering.  My feeling is that whatever our behavior is, if
it's correct, it should be at least consistent.

The problem fixes itself when you:

1.  Click in the URL bar 
2.  Use the vertical scrollbar

Robert, don't these point to reflow events?  I'm asking, because why would our
behavior change from initial load/layout to the events listed above?

Comment 16

[Stephen Donner [:stephend] Not actively reading bugmail]

Talked to Boris on IRC (hope you don't mind me quoting you)...

<bz> but we have a painting issue
<bz> that's not visible on Linux because of another bug
<bz> On Linux we tend to overpaint
<bz> and so paint more than the area we should
<bz> and the bug is that sometimes the area we think we should paint is too
small.  ;)

Also note that if I resize the window or drag another window over it (or even
just simply do a File | New Window), the area gets repainted.

I've looked for the corresponding DUP in layout:views and gfx:win, but it's
eluding me at this present moment.

Comment 17

[Mats Palmgren (inactive)]

Comment on attachment 131909 [details]
New minimalized testcase.

This testcase does not reflect the original reported problem and renders as
expected.

Comment 18

[Mats Palmgren (inactive)]

First attachment WFM, Mozilla 1.5 and 2003-10-18-05 trunk Linux

Comment 19

[Stephen Donner [:stephend] Not actively reading bugmail]

I believe this bug is fixed now due to Boris's checkins for bug 217225.

Since I only have one platform, can anybody else confirm?  Win2k, self-built
MingW build pulled right after his checkin.

Comment 20

[Stephen Donner [:stephend] Not actively reading bugmail]

(Though I'll duly note that
http://bugzilla.mozilla.org/attachment.cgi?id=126157&action=view still doesn't
work for me, but that could be another issue).

Comment 21

[Boris Zbarsky [:bzbarsky]]

I doubt that checkin would have affected the behavior here... At least I really
hope it did not.

Comment 22

[James Ross]

Using a Firebird build from 20040110, I get the described problem on the first
attachment. It appears to be a problem with redraw (I figure it's not
invalidating enough), not layout. I found editing the border of the #main-body
once it's loaded is enough to make it draw properly.

It appears to be caused by the inclusion of this
<http://www.netflix.com/jscript/shared.js> script in the source. If I remove the
<script> tag that includes it, I can no longer reproduce the error. I have not
looked at what the script does.

Comment 23

[Arno Fiege]

Attachment: testcase

Tried to make a simplified testcase. If you remove the external javascript the
problem is solved. The loading slows down painting or something with seems to
cause it to just forget a little.

Also tested my testcase on firebirds latest 0.8 branch:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20040102
Firebird/0.7+

and the result seems to be a little worse than on the official firebird 0.7 and
Mozilla Suite 1.5 releases.

Hope this helps. :)

Comment 24

[James Ross]

Yes, it seems the delay loading the script is critical. What happens, as far as
I can see, is it paints the current page when it gets to the script. In the 4th
attachment, the state of the page has the text flowing /beyond/ the box with the
black border. After the script has loaded, and the parser's dealt with the rest
of the page, it paints again. The gap is from the bottom of the black box before
the script, to the bottom of the text.

Something tells me this is a case of replainting the box's old "size" (possibly
the wrong layout term, but I mean the dimensions in terms of border, etc., not
contents), and also the difference in "bounding boxes" from it's old to new
sizes - note that these don't meet up, because the text extended beyond the
black box.

Comment 25

[James Ross]

(from attachment.cgi 138966)
 955 Invalidate widget=12E40494 id=009702BE rect=none            sync=no
 964 Invalidate widget=12E40494 id=009702BE rect=  0,0   603,151 sync=no
 965 PAINT      widget=12E40494 id=009702BE rect=  0,0   602,150
 969 Invalidate widget=12E40494 id=009702BE rect=158,33  417,15  sync=no
 970 Invalidate widget=12E40494 id=009702BE rect= 44,47  531,15  sync=no
 971 Invalidate widget=12E40494 id=009702BE rect=  8,8   587,36  sync=no
 972 Invalidate widget=12E40494 id=009702BE rect=  8,47  587,25  sync=no
 973 Invalidate widget=12E40494 id=009702BE rect=  8,47  587,25  sync=no
 978 PAINT      widget=12E40494 id=009702BE rect=  8,8   587,64

c.f. rows 971 and 972/973. These are leaving the gap (8 + 36 = 42 < 47).

Comment 26

[James Ross]

Attachment: Full layout log

Comment 27

[Stephen Donner [:stephend] Not actively reading bugmail]

This really is a DUP of bug 244017, as I was experiencing this bug all of the
time, and now I can see it reflow and fix the borders on Netflix.com.

Build

*** This bug has been marked as a duplicate of 244017 ***

Comment 28

[Stephen Donner [:stephend] Not actively reading bugmail]

This really is a DUP of bug 244017, as I was experiencing this bug all of the
time, and now I can see it reflow and fix the borders on Netflix.com.

Build 20040629, Windows XP.

*** This bug has been marked as a duplicate of 244017 ***

*** This bug has been marked as a duplicate of 244017 ***