7585 - infinite loop in layout?

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[stevenj]

Go to store.apple.com, and click on the image of the PowerBook G3 (middle image,
top of the page).  This is supposed to bring up a page where you can buy this
computer.  However, when I do this in Mozilla M6, it loads part of the way, and
then stalls, never finishing (at least, not after 10 minutes).  (The animation
and "barberpole" progress bar keep running, and I can click the back button or
do other things, so it hasn't hung.)  It's not that the server is slow because I
can view the same page in Navigator 4.04 with little delay, or even use the
"View Source" Mozilla M6 menu item to see the complete HTML source for the page.

Comment 1

[rickg]

V -- can you help out on this one? I don't think it's your bug, but if you were
to help me find out the cause, I'd be greatful since I went away for 2 days and
came back to 100 bugs. :(

Comment 2

[John Morrison]

Short observations:

(1) the 'powerbook' image is a server-side imagemap, which is bug #652, not
yet implemented -- current behaviour is to load the image itself, rather than
the targetted page -- so _loading_is_successful_, but not what the end user
expects to see (compared to 4.5)

(2) the 'barberpole' does continue to spin (for whatever reason) giving poor
end user feedback even though the image has loaded. I suppose this issue would
be in the apprunner/xptoolkit domain.

Comment 3

[vidur (gone)]

I can't look at this bug till the Necko problem with charset specifications in
the content-type field of the HTTP header is fixed. Currently, the charset
information isn't getting parsed out of the content type and type-based lookup
in the component manager is failing.

(There's a secondary bug because META tag refreshes aren't working either, but
the bug described above is the one that's not easy to work around.)

Comment 4

[Judson Valeski]

it turns out we're not going to bother setting headers back in necko that come
in from meta http-equiv tags. I've got a fix for the refresh stuff I'm cleaning
up (10720). I think ftang is our meta charset guy.? I'm removing the connection
between this bug and 10720 as we're not going to set these headers anymore.

Comment 5

[vidur (gone)]

Actually the problem is because the charset information is included in the
content type of the actual HTTP header (not one from a META http-equiv). The
charset information in the header should be stripped out and Rick Potts agress
that it's his bug.

Comment 6

[rpotts (gone)]

hey vidur,

it looks like you've fixed this bug :-)  Once I stripped out the CharSet info
from the content-type the page loads fine !!

-- rick

Comment 7

[Frank Tang]

Add [e-mail],[e-mail] to cc list
[e-mail],[e-mail]: could you verify this with the test page
we have about HTTP header and see are they cause infinite loop or not.

Comment 8

[vidur (gone)]

HTTP header problem fixed by Rick Potts. It's quite possible that the content
has changed substantially, but I don't see the original problem anymore. Given
the large modifications at both the networking and the doc loader level, I'm not
surprised.

Comment 9

[Chris Petersen]

With the Aug 16th Build, this problem has been fixed.