We need to enable redirects in order to browse some of the top sites that use redirects. For example, almost all banner ads use a redirect (you click, it logs the ad, and redirects you to the advertister site).

reassigning to rpotts since he's the netlib guru...

Orignal test case url was: http://warp/bonsai http://warp/bonsai actually takes you through multiple redirects. http://warp/bonsai <enter> gives you an http redirect which works (it takes you to the page that tells you you're going to be redirected). This page is http://warp.netscape.com/webtools/bonsai/ which contains an html http-equiv meta tag with "Refresh". This is the redirect that is broken. There are three types of redirects: 1. http redirects (302 "temporarily moved" server responses) - These are working as they are netlib dependent. Here's an example of one: http://warp/bonsai 2. javascript redirects - javascript implementation dependent. Last time I tried (http://people.netscape.com) this wasn't working. 3. http-equiv "Refresh" meta tag redirect - These are broken as our current parsing code doesn't prompt the reload (I'm not sure where it's actully parsing them yet). The windows front end on gromit sets a timer that refreshes the url every X seconds, or once (essentially a redirect). We don't have an equivelent yet in raptor.

The previous example of a javascript example is no good. Use http://lotus/jsredirect.html . If you see the text "jsredirectdest.html" you were successfully redirected.

Adding vidur to the "cc:" list since he will probably hook up the window.location= type of "redirect," if it's even right to call it that.

Yeah, window.location is next on my list. It won't be there for upcoming demo, though.

302 redirects don't work. For a test case, try clicking the "My Netscape" button on the Netscape home page. I wasn't sure if Jud was aware of this issue, so I'm making note of it here.

I'm confused. The my netscape button doesn't do a redirect at all. 302's work except for a glitch I have to check in. (www.pcmagazine.com doesn't work even thought it's a 302).

Apologies for the confusion - you're right, the My Netscape button on our home page doesn't do a 302 redirect. It's also a link in a client-side image map, which could be complicating things. Currently, you click on the button, and it loads this URL: http://home.netscape.com/netcenter/personalize/index.html Which tries to "redirect" you to my.netscape.com using this code either JavaScript or META refreshes: <SCRIPT LANGUAGE="JavaScript1.1"> <!-- document.location.replace("http://my.netscape.com/index.html"); //--> </SCRIPT> <META HTTP-EQUIV="Refresh" CONTENT="0; URL=http://my.netscape.com/index.html">

I'll take the bug. I already checked in window.location. document.location is a short step behind. Angus, could you check it out again after I commit my changes today?

I just checked in my fix for this (8/13/98 1:13pm) into the tip. It fixes redirects that come in via meta http-equiv refresh tags.

My test case involves going to www.netscape.com and clicking on the "My Netscape" icon at the head of the page. I crash when doing this now. The stack trace is as follows: nsHTMLTagContent::AddScriptEventListener(nsIAtom * 0x01064cc0, nsHTMLValue & {...}, const nsID & {...}) line 408 + 11 bytes nsHTMLTagContent::SetDocument(nsIDocument * 0x0119cd40) line 265 nsHTMLContainer::AppendChild(nsHTMLContainer * const 0x0118d590, nsIContent * 0x0118d690, int 0) line 195 HTMLContentSink::AppendToCorrectParent(nsHTMLTag eHTMLTag_font, nsIHTMLContent * 0x0118d590, nsHTMLTag eHTMLTag_a, nsIHTMLContent * 0x0118d690, int 0) line 1452 HTMLContentSink::CloseContainer(HTMLContentSink * const 0x01470c08, const nsIParserNode & {...}) line 909 CNavDTD::CloseContainer(const nsIParserNode & {...}, nsHTMLTag eHTMLTag_a, int 1) line 2640 + 22 bytes CNavDTD::CloseContainersTo(int 18, nsHTMLTag eHTMLTag_a, int 1) line 2674 + 20 bytes CNavDTD::CloseContainersTo(nsHTMLTag eHTMLTag_a, int 1) line 2695 + 20 bytes CNavDTD::HandleEndToken(CToken * 0x0115c600) line 933 + 17 bytes NavDispatchTokenHandler(CToken * 0x0115c600, nsIDTD * 0x01455600) line 419 + 12 bytes CTokenHandler::operator()(CToken * 0x0115c600, nsIDTD * 0x01455600) line 80 + 14 bytes CNavDTD::HandleToken(CNavDTD * const 0x01455600, CToken * 0x0115c600) line 679 + 18 bytes nsParser::BuildModel() line 586 + 16 bytes nsParser::ResumeParse() line 551 nsParser::OnDataAvailable(nsParser * const 0x0119c214, nsIURL * 0x01196e80, nsIInputStream * 0x0119c970, int 7300) line 761 + 15 bytes nsDocumentBindInfo::OnDataAvailable(nsDocumentBindInfo * const 0x01196e20, nsIURL * 0x01196e80, nsIInputStream * 0x0119c970, int 7300) line 1056 + 30 bytes stub_put_block(_NET_StreamClass * 0x0119c920, char * 0x00ff9278, long 7300) line 566 + 36 bytes net_MemCacheWrite(_NET_StreamClass * 0x01095120, char * 0x00ff9278, long 7300) line 661 + 24 bytes net_pull_http_data(_ActiveEntry * 0x01196680) line 3003 + 29 bytes net_ProcessHTTP(_ActiveEntry * 0x01196680) line 3389 + 9 bytes NET_ProcessNet(PRFileDesc * 0x01151600, int 2) line 3297 + 13 bytes NET_PollSockets() line 180 + 18 bytes nsNetlibService::NetPollSocketsCallback(nsITimer * 0x01109310, void * 0x01023e60) line 488 TimerImpl::Fire(unsigned long 11612527) line 321 + 17 bytes TimerImpl::ProcessTimeouts(unsigned long 11612527) line 199 FireTimeout(void * 0x00000000, unsigned int 275, unsigned int 23402, unsigned long 11612527) line 103 + 9 bytes USER32! 77e7128c() main(int 1, char * * 0x01005210) line 95 mainCRTStartup() line 338 + 17 bytes KERNEL32! 77f1b304() &#137;

The test that you mentioned works for me. The crash that you got was a Tom Pixley bug that I think he has subsequently fixed. I'm going to close this one.

Verified fixed on 2.1.99 Win32 and Mac OS builds. However, the test case described (my.netscape.com) crashes Linux reproducibly. So, I'll simplify the test case and determine whether or not the redirect is in fact bringing about the crash, and then verify or re-open the bug as appropriate.

Re-opening on Linux (1.29.99 build used, Viewer) Specifically, on a simplified redirect test case (as provided by Angus, slightly tweaked for dead URL, at http://www.prometheus-music.com/gecko/bug563.html), Viewer on Linux pauses for about 5-10 seconds (displaying a blank page), and then dies. The console log says: handle_size_allocate: top level resize Timer::Init() called with bogus value "-1073743640"! Not enabling timer.

Eli, what kind of redirect is this? Javascript? (I can't see the source).

A Linux-specific problem that relates to timers. I'm happy to help, but this doesn't look like a JavaScript redirect problem anymore.

I just tried this on both apr 6 nt and linux builds and it works fine. marking worksforme.

verified. The URL field doesn't update on the re-direct, I believe there is a separate bug filed on this.

Changing all Networking Library/Browser bugs to Networking-Core component for Browser. Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do this in a bulk change. If this happens, I will fix. ;-)

Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.