102717 - ESPN.com homepage appears to layout twice on initial load

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Todd Pringle]

Build ID:  20011002

Steps to reproduce:

1) Launch navigator
2) Visit http://espn.go.com/main.html

Result:  Page appears to layout twice
Expected Result:  Page should only layout once
Reproducible:  Always

Not sure if this is a client issue or an evangelism issue.

Comment 1

[Todd Pringle]

Marking nsbranch+ to get on the radar, this is a high visibility site and a
regression from 6.1.

Comment 2

[Marc Attinasi]

I'm not seeing this with my just-pulled-down-trunk-build: Gecko/20011002 on
Windows 2000.

Branch or trunk?

Comment 3

[Olivier Cahagne]

confirming on Win2k with build 2001100203: the window "blinks" one, so layout twice.

Comment 4

[Todd Pringle]

Sorry, I'm on the branch.

Comment 5

[Kevin McCluskey (gone)]

I'm seeing the problem with a trunk build. May be timing related. I'm on a
relativly slow machine 433Mhz, compared to Marc. 

Most of the page is loaded then it will paint a black rectangle to the left and
a white rectangle over the content area, then it will load the rest of the page
and paint it correctly.

My guess is the frames are being destroyed after most of the document has been
constructed, followed by new frames being built.

CC'ing waterson. 

Anthony: Could you help build a reduced test case?

Comment 6

[Kevin McCluskey (gone)]

Reassigning to Chris K.

Comment 7

[Chris Petersen]

This problem is noticeable on the Mac OS X branch build (2001-10-02-04).

Comment 8

[karnaze (gone)]

Attachment: reduced test case

Comment 9

[karnaze (gone)]

Attachment: reduced test case without style sheet

Comment 10

[karnaze (gone)]

In the test case I see the left hand black area (due to the repeated background 
image on the body) appear without the submit button and then the submit button 
appears after a split second delay. I'm using a 1.3MHZ processor. I substituted 
a table for the submit button and verified that its frame wasn't being destroyed 
or reflowed unnecessarily. The absolute positioning on the div doesn't appear to 
be the problem either which leaves (a) the background repeated image or (b) the 
flash animation. 

Comment 11

[Kevin McCluskey (gone)]

I'm using a release build from today on 750Mhz WINNT machine. Even though I
clear my cache each time before reloading espn, I don't always see it
repainting. Sometimes it repaints other times it doesn't. It is definitely
timing related. 

Chris does see tables being destroyed in the debugger after the page has started
loading as a result of style sheet being added through a document.write call in
espn's JavaScript. However, this is the normal behavior when style sheet is added.

This really looks like its related to when an external sheet is loaded as the
result of a document.write.

I am going to mark it nsbranch- for now. I don't think this a "stop-ship" issue. 

Chris will do some further investigation.

Comment 12

[karnaze (gone)]

Temporarily moving to future until a milestone can be assigned. 

Comment 13

[anthonyd]

i have a slow machine, and I am not seeing this, i DO see the blink, but for me 
the blink is BEFORE the page laysout even a part of it.  has anyone gone and put 
a breakpoint on some piece of the layout code that should be hit only once or 
something and see if it is being hit twice?  I don't know.

I notice there arent any table in the reduced testcase, so im going to reassign 
this to core owner.

Comment 14

[Todd Pringle]

I have not seen this for awhile on the trunk, marking worksforme.  If anyone
else is still seeing it, go ahead and reopen.