infinite loop in layout?




20 years ago
19 years ago


(Reporter: stevenj, Assigned: vidur)


Mac System 8.5

Firefox Tracking Flags

(Not tracked)





20 years ago
Go to, 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.


20 years ago
Assignee: rickg → vidur

Comment 1

20 years ago
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

20 years ago
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.


20 years ago
Depends on: 10720, 11133

Comment 3

20 years ago
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.)


20 years ago
No longer depends on: 10720

Comment 4

20 years ago
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

20 years ago
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

20 years ago
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

20 years ago
Add, to cc list, could you verify this with the test page
we have about HTTP header and see are they cause infinite loop or not.


19 years ago
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 8

19 years ago
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

Comment 9

19 years ago
With the Aug 16th Build, this problem has been fixed.
You need to log in before you can comment on or make changes to this bug.