infinite loop in layout?

VERIFIED FIXED

Status

()

P3
major
VERIFIED FIXED
20 years ago
19 years ago

People

(Reporter: stevenj, Assigned: vidur)

Tracking

Trunk
PowerPC
Mac System 8.5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

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

Updated

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.
(Assignee)

Updated

20 years ago
Status: NEW → ASSIGNED
Depends on: 10720, 11133
(Assignee)

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.)

Updated

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.
(Assignee)

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 blee@netscape.com,teruko@netscape.com to cc list
blee@netscape.com,teruko@netscape.com: could you verify this with the test page
we have about HTTP header and see are they cause infinite loop or not.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

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
surprised.

Comment 9

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