I've tracked this down as far as seeing that the crash is due to cd->proxy_server being 0x1. As to WHY its this value, not sure. I don't have a proxy server setup. (gdb) bt #0 0xee1245b0 in strlen () #1 0xee705334 in cvt_s (ss=0xefffe378, s=0x1 "O", width=0, prec=-1, flags=0) at prprf.c:369 #2 0xee707568 in dosprintf (ss=0xefffe378, fmt=0xeeb6d314 "", ap=0xefffe664) at prprf.c:971 #3 0xee707dc0 in PR_vsnprintf (out=0xefffe400 "NET_FinishConnect called for url: ", outlen=512, fmt=0xeeb6d2f0 "NET_FinishConnect called for url: %s", ap=0xefffe660) at prprf.c:1180 #4 0xeeb5f3bc in _MK_TraceMsg (fmt=0xeeb6d2f0 "NET_FinishConnect called for url: %s") at ../../../mozilla/network/main/mktrace.c:86 #5 0xeeb45f80 in NET_FinishConnect (url=0x1 "O", prot_name=0xeecf7b20 "HTTP", def_port=80, sock=0x43434c, tcp_con_data=0x4424a4, window_id=0x442318, error_msg=0x45cf00, localIP=0) at ../../../mozilla/network/main/mkconect.c:1311 #6 0xeece5df4 in net_finish_http_connect (ce=0x45d7e0) at ../../../../mozilla/network/protocol/http/mkhttp.c:611 #7 0xeecee618 in net_ProcessHTTP (ce=0x45d7e0) at ../../../../mozilla/network/protocol/http/mkhttp.c:3446 #8 0xeeb4e288 in NET_ProcessNet (ready_fd=0x30fea0, fd_type=2) at ../../../mozilla/network/main/mkgeturl.c:3367 #9 0xeeb5a640 in NET_PollSockets () at ../../../mozilla/network/main/mkselect.c:320 #10 0xeebdaed8 in nsNetlibService::NetPollSocketsCallback (aTimer=0x44ef30, aClosure=0xb33d0) at ../../../mozilla/network/module/nsNetService.cpp:1217 #11 0xeefe526c in TimerImpl::FireTimeout (this=0x44ef30) at ../../../../mozilla/base/src/gtk/nsTimer.cpp:73 #12 0xeefe5a80 in nsTimerExpired (aCallData=0x44ef30) at ../../../../mozilla/base/src/gtk/nsTimer.cpp:188 #13 0xee488044 in g_timeout_dispatch (source_data=0x4344c8, current_time=0xeffff5a0, user_data=0x44ef30) at gmain.c:1122 #14 0xee486f24 in g_main_dispatch (current_time=0xeffff5a0) at gmain.c:640 #15 0xee48755c in g_main_iterate (block=1224, dispatch=1) at gmain.c:829 #16 0xee48776c in g_main_run (loop=0x1a7a98) at gmain.c:887 #17 0xee5c11c0 in gtk_main () at gtkmain.c:457 #18 0xef7076e8 in nsAppShell::Run (this=0xd2f50) at ../../../../mozilla/widget/src/gtk/nsAppShell.cpp:145 #19 0x286b8 in nsNativeViewerApp::Run (this=0xd0c38) at ../../../../mozilla/webshell/tests/viewer/nsGTKMain.cpp:42 #20 0x28a44 in main (argc=2, argv=0xeffff864) at ../../../../mozilla/webshell/tests/viewer/nsGTKMain.cpp:97 (gdb) up #1 0xee705334 in cvt_s (ss=0xefffe378, s=0x1 "O", width=0, prec=-1, flags=0) at prprf.c:369 prprf.c:369: No such file or directory. Current language: auto; currently c (gdb) #2 0xee707568 in dosprintf (ss=0xefffe378, fmt=0xeeb6d314 "", ap=0xefffe664) at prprf.c:971 prprf.c:971: No such file or directory. (gdb) #3 0xee707dc0 in PR_vsnprintf (out=0xefffe400 "NET_FinishConnect called for url: ", outlen=512, fmt=0xeeb6d2f0 "NET_FinishConnect called for url: %s", ap=0xefffe660) at prprf.c:1180 prprf.c:1180: No such file or directory. (gdb) #4 0xeeb5f3bc in _MK_TraceMsg (fmt=0xeeb6d2f0 "NET_FinishConnect called for url: %s") at ../../../mozilla/network/main/mktrace.c:86 86 PR_vsnprintf(buf, sizeof(buf), fmt, ap); (gdb) #5 0xeeb45f80 in NET_FinishConnect (url=0x1 "O", prot_name=0xeecf7b20 "HTTP", def_port=80, sock=0x43434c, tcp_con_data=0x4424a4, window_id=0x442318, error_msg=0x45cf00, localIP=0) at ../../../mozilla/network/main/mkconect.c:1311 1311 TRACEMSG(("NET_FinishConnect called for url: %s", url)); (gdb) #6 0xeece5df4 in net_finish_http_connect (ce=0x45d7e0) at ../../../../mozilla/network/protocol/http/mkhttp.c:611 611 ce->status = NET_FinishConnect(cd->proxy_server, (gdb) print *cd $1 = {next_state = HTTP_FINISH_CONNECT, proxy_server = 0x1 "O", proxy_conf = 0x0, line_buffer = 0x0, server_headers = 0x0, orig_host = 0x0, partial_cache_fp = 0x0, partial_needed = 0, total_size_of_files_to_post = 0, total_amt_written = 0, line_buffer_size = 0, connection = 0x434348, stream = 0x0, pause_for_read = 0 '\000', send_http1 = 1 '\001', acting_as_proxy = 0 '\000', server_busy_retry = 0 '\000', posting = 0 '\000', doing_redirect = 0 '\000', save_redirect_method = 0 '\000', sent_authorization = 0 '\000', sent_proxy_auth = 0 '\000', authorization_required = 0 '\000', proxy_auth_required = 0 '\000', destroy_graph_progress = 0 '\000', destroy_file_upload_progress_dialog = 0 '\000', protocol_version = POINT_NINE, original_content_length = 0, tcp_con_data = 0x45eac0, use_proxy_tunnel = 0 '\000', proxy_tunnel_setup_done = 0 '\000', use_copy_from_cache = 0 '\000', displayed_some_data = 0 '\000', save_connection = 0 '\000', partial_cache_file = 0 '\000', reuse_stream = 0 '\000', connection_is_valid = 0 '\000', write_post_data_data = 0x0}

setting paulmac as QA contact for all gagan's bugs (sorry for the spam)

New netlib wont have these problems. It will have others :-)

Per DP's suggestion marking these till M8. Though Necko lands with M7, we will be able to verify it for M8.

I'm moving this to target M9, Necko will be enabled somewhere during late M8 or early M9. We will need to get on this and it cannot be postponed past the M9 milestone.

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

Should be fixed with Necko. Pl. verify.

This URL is crashing immediately, but I don't suspect it is happening in necko. Gagan, can you look at this in a debugger? I don't get stack traces in Linux.

disney.com redirects to go.com and then all hell breaks loose...! :) Cc'ing Rick for his comments.

disney.com redirects to go.com and then all hell breaks loose...! :) Cc'ing Rick for his comments.

disney.com redirects to go.com and then all hell breaks loose...! :) Cc'ing Rick for his comments.

M9 on NT doesn't crash, but gives me a blank page, when the redirect comes (or after? The Location URL doesn't change, but apprunner says it has loaded disney.go.com).

Works ok now. Loads the redirected page correctly. Someone in Layout land should look at why its coming up empty. Might be some plugins stuff.

Somehow everything is ending up in the HEAD of the document. Here's what the dump of the content model shows for BODY body refcount=3< Text refcount=3<\n\n\t\n \n\t\n\t\n\t\n\t\n\t\n\n\n\t\n\t\n\t\n\t\n\n\n\n \n\n\n\n\n \n> >

update title to the latest behavior.. who should be the proud owner?

On W98, as of 1999-09-25-08 build, the header and footer parts come up fine. The rest is one big flash object. So I guess unless we have a flash plugin, there is not much we can do about it... Is the parsing problem still a problem?

Assigning bug to myself. Will investigate this today...

Ok, this is what I found. Relative URIs are not redirected properly. Do the following: 1. Open Navigator and type "view-source:www.disney.com" 2. Save the source 3. Replace the relative urls with absolute, i.e., top.location.replace("/home/homepage....") should be replaced with top.location.replace("http://home/homepage/....") 4. Load the saved document in viewer/apprunner.

adding myself to the CC list.

The problem is slightly different from what Harish posted earlier. The redirection problem is gone. So, www.disney.com redirects to disney.go.com properly and data comes through. But, necko is sending in a malformed document when I load http://disney.go.com from the network. When I load up a locally saved version of disney.go.com (saved after cutting and pasting the contents of view-source:http://disney.go.com), necko sends in a valid document. I'm attaching four files and re-assigning this bug to chofmann who can pass it along to the right necko person for the job: a) The locally saved version of http://disney.go.com (bug3118.html) b) The debug output showing the buffer sent in by necko when http://disney.go.com is retrieved from the network (netlib_remote.txt) c) The debug output showing the buffer sent in by necko when bug3318.html is loaded up locally (netlib_local.txt) d) The patch that prints out the debug output (bug3818.patch) Compare b) and c) and you'll find that the document in b) is totally horked.

Oops, corrections to the previous post: substitute bug3318.html and bug 3818.html with bug3118.html. Seems like I can't remember a simple bug number for longer than 2 minutes! :-)

Well, this is a completely different bug now than when this report started. Maybe we should start over. Still goes to Gagan though.

will release note for M10. Moving to M11.

Problem still exists in 110108 builds, all platforms.

Putting on [PDT+] radar.

This is really whacky... in its latest incarnation of this bug, we pull the document absolutely fine (so necko is not the problem) but this page has some nasty self referencing document.writeln with which it generates stuff on the fly... Over to JS land...(also corrected the doc location now)

Argh... just noticed that occasionally the connection is being reset by the host before the end is reached. And that seems to be corrupting the amount of length to read which is now different from teh amount available for read. Taking it back over...

Well... that last comment seems to have been an isolated case... we do push the whole file up correctly to the observer. I noticed a bunch of Javascript errors on the console... and so I think its best if it gets evaluated by someone in JS land! Mccabe?

Is this what you mean? JavaScript Error: missing } in compound statement URL: http://disney.go.com/ LineNo: 86 Line text: '//--> ' That's exactly what would happen if there was a mismatch between the text and the amount the JS engine was told to parse; looks like it's going beyond the end. This is exactly what you mentioned in your earlier comment. Assigning back.

They've got a white space problem, that's all. <A HREF="http://www.singleclick.com/~jelwell/test1.html">Disney fix.</A> All I did was: lynx -source "http://disney.go.com/" > index.html ; dos2unix index.html Then I opened index.html in vi and made the code more readable, added newlines mostly (I properly indented the code too, but that shouldn't matter). The only other change I made was to add "http://disney.go.com/" to the top.location.replace calls - so they would point to the right page. I have a feeling that Disney is commenting out their Javascript, but I can't prove it. I notice that both vi and Mozilla's View Source think that *ALL* of disney.com's javascript is on _ONE_ line. That includes single line comments like // Comment. var blah; document.location = "http://www.disney.com"; That's no good, because then the code is commented out. If I open the source in Navigator 4.08 (by hitting escape faster than it loads the new site: turning of javascript won't help) Navigator sees pretty source code with plenty of newlines. Is Mozilla ignoring some non-standard newline? Mac Newlines?

Ignore my last link to singleclick. Here's the working link: http://www.singleclick.com/~jelwell/disney/test1.html

I think I know whats going on here... may need some JS help. I believe the \r is not being recognized alone as the end of line in JS and so everything following a // comment gets lost.

*** Bug 19124 has been marked as a duplicate of this bug. ***

Harish, after talking to mccabe I will have to hand this bug to you. It looks like the parser is not recognizing the \r correctly. I wrote a small filter that converted \r to \n and everything worked ok. And as far as Necko goes I see the complete data get passed. So based on this it looks like an HTML Parser problem. If you need any more help on this bug contact me on gagan@netscape.net (May be checking that sporadically)

Taking from Harish, who is jetting his way to india. Estimated time to fix: 12/3.

Fixed by adding hack upon hack to CObserverService::Notify(). I've opened another bug on Harish to fix the original hack.

excellent hackery, marking verified on all platforms with 11/23 builds