From Bugzilla Helper: User-Agent: Mozilla/4.74 [en] (X11; U; Linux 2.2.16 i686; Nav) BuildID: 2000090806 When loading the above page, mozilla gets itself into an infinite loop of redirects; older versions of netscape render the page upon going to the above URL. Reproducible: Always Steps to Reproduce: 1. Go to the above page... 2. Watch your webshells count yoyo; page never gets rendered. Actual Results: Mozilla gets caught up in redirects (I think), and sits there, with its webshell count going up and down by three, never rendering the page... Expected Results: Should load the page...NS 4.74 has no problems doing so. ...general startup info... Document about:blank loaded successfully ->>>>>>>>>>>>>> Write Clipboard to memory ->>>>>>>>>>>>>> Read Clipboard from memory ->>>>>>>>>>>>>> Write Clipboard to memory WEBSHELL+ = 4 WEBSHELL+ = 5 WEBSHELL+ = 6 WEBSHELL+ = 7 WEBSHELL+ = 8 WEBSHELL- = 7 WEBSHELL- = 6 WEBSHELL- = 5 WEBSHELL+ = 6 WEBSHELL+ = 7 WEBSHELL+ = 8 WEBSHELL- = 7 WEBSHELL- = 6 WEBSHELL- = 5 WEBSHELL+ = 6 WEBSHELL+ = 7 WEBSHELL+ = 8 WEBSHELL- = 7 WEBSHELL- = 6 WEBSHELL- = 5 WEBSHELL+ = 6 WEBSHELL+ = 7 WEBSHELL+ = 8 ...etc...
This bug is INVALID (suggest as such, since I can mark it as such) The reason for the reload is, that there is in the <header>: <noframe><meta http-equiv="reload"> Since noframe in the header is *not* valid and http-equiv cannot be escaped, the reload is done.
If this is *really* against the RFC's or W3, then that makes sense; but I suppose *my* question is why NS 4.7x renders the page, if it's so horribly standards-incompliant. Well...maybe you don't need to answer that. :-) But, this sort of html will...DOS mozilla of sorts (the renderer basically stops while all of this yo-yo-ing is going on); would there be any way to either a) just make it work, or (if that's horrendously unacceptable) b) make mozilla go "I'm in a loop, and I shouldn't be...ignore this stupid html(tm)." I actually figured it was something that the html-writer was doing that wasn't standards compliant, aka stupid, but I still think it shouldn't throw mozilla into a tizzy, and NS 4.7x *does* get it right.
See it on 2000 too. Marking as NEW for future decision.
OS: Linux → All
Browser, not engine. Changing component to Browser-General for further assignment (not sure of the exact component on this one) -
Assignee: rogerl → asa
QA Contact: pschwartau → doronr
Status: UNCONFIRMED → NEW
Ever confirmed: true
related: bug 46115. cc'ing owner of that bug.
really over to networking now
Assignee: asa → gagan
Component: Browser-General → Networking
QA Contact: doronr → tever
Assignee: gagan → ruslan
Gagan, why is this bug assigned to networking?
Assignee: ruslan → gagan
Status: ASSIGNED → NEW
It should be noted the the page actually does display with build 2000091908 (a bit old, I know). The infinite redirect loop is still there, and fortunately, is a bit more visible (the left content window keeps trying to get loaded in the main content window) in these later builds.
Hmmm... Now that I read more about it, I guess I have to mark it INVALID.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → INVALID
No. Mozilla is not expected to repeat the same mistakes as NS4.* Unless you can convince me that this style of usage is of any use, I'd like to leave this invalid.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.