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.
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. :(
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.
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.)
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.
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.
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
Add firstname.lastname@example.org,email@example.com to cc list firstname.lastname@example.org,email@example.com: could you verify this with the test page we have about HTTP header and see are they cause infinite loop or not.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
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.
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.