To reproduce: 1. goto http://www.microsoft.com/downloads/ 2. Select "Windows 98" in "Operating System" combo. 3. Click "Find It!" Expected: This should display a list of approx. 25 items. (Form elements should keep their selected values.) Actual: No search results are displayed and form elements are reset. Additional info: An error message was displayed in the console window: Document http://www.microsoft.com/downloads/default.asp loaded successfully Document: Done (46.25 secs) url=http://www.microsoft.com/downloads/default.asp data=Content-type: application/x-www-form-urlencoded; charset=windows-1252 Referer: http://www.microsoft.com/downloads/default.asp Content-Length: 70 Search=Product&LangIDCODE=20%3Ben%2Dus&Value=0&OpSysID=9800&Show=Alpha Error: Can't load: http://www.microsoft.com/downloads/default.asp (804b0002) Document http://www.microsoft.com/downloads/default.asp loaded successfully Document: Done (39.88 secs) ----- I was using nightly build 1999-08-16-09-M9 on Windows 98. PS. I did see bug#11703 filed against the same URL, but after analyzing the page source I think this is a separate problem.

Reassigning to Kevin

Its getting all of the info out of the form elements and looks like its composing the post buffer correctly. data=Content-type: application/x-www-form-urlencoded; charset=windows-1252 Referer: http://www.microsoft.com/downloads/default.asp Content-Length: 70 Search=Product&LangIDCODE=20%3Ben%2Dus&Value=0&OpSysID=9800&Show=Alpha The problem must be in the post. rv = NS_NewPostDataStream(!isURLEncoded, postBuffer, 0, &postDataStream); Reassigning to necko.

any volunteers to watch the HTTP traffic and see the difference?

Buy me a copy of EtherPeek from the AG Group and I'll volunteer, sure. Seriously, I don't have the tools to do that. If anyone has an EtherPeek machine at Netscape, I can use that to have a look at the traffic. If not, if anyone wants to show me how to do it in another product, I'm always willing to learn.

we have a copy of TracePlus in the test lab that should suffice.

I've got a server running on blueviper that, if you submit a form to port 8000, will echo back to you the exact text of the request it received. You'll have to edit the HTML file to point at "http://blueviper:8000/blah blah blah..." I'll run this test to see what turns up...

Nav posts: -------- POST /default.asp HTTP/1.0 Referer: http://blueviper/forms/msdown.html Connection: Keep-Alive User-Agent: Mozilla/4.7 [en] (X11; I; Linux 2.2.12-23 i686) Host: blueviper:8000 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8 Content-type: application/x-www-form-urlencoded Content-length: 68 Search=Product&LangIDCODE=20%3Ben-us&Value=0&OpSysID=9800&Show=Alpha -------- We post: -------- POST /default.asp HTTP/1.0 host: blueviper accept: */* user-agent: Mozilla/5.0 [en-US] (LINUX; I) referer: http://blueviper/forms/msdown.html Content-type: application/x-www-form-urlencoded; charset=windows-1252Content-Length: 68 -------- Opps! Looks like no data is posted, I'm looking at this.

Okay I traced that part of this bug down, I accidentally removed an extra line of code when removing the Referer header yesterday. I'll check in that fix asap. This bug still is present though, I'm lookin'...

The remaining bug is because we aren't appending out data stream with a CRLF, fixing...

This is now fixed, but the bug remains. Drat. I can't figure out what the problem is. I'm working on an HTTP proxy written in perl to help my trace bugs like this down, will have it done today sometime hopefully. :)

It looks like HTTP is sending the POST requset correctly *and* getting the data back... However, the HTML parser is returning NS_ERROR_HTMLPARSER_STOPPARSING after receiving the first chunk of data... what causes the parser to return this error code? Could the response have a meta-charset tag which is causing the page to get reloaded?

When viewing this site in IE 5.0, the page is dynamically modified using all kinds of nasty (i.e. non-standard DOM) jscript. This site is treating is as though we are IE and can handle all of this, which is why it's not displaying search results. I'm tempted to mark this WONTFIX, but I think we should resolve the parser error first. Harish, can you take a look? I'm getting this on the console, it's the same assertion in SinkContent::End() you noticed Friday when searching at Go.com/excite.com then clicking on the site in the search menu. url=http://www.microsoft.com/downloads/default.asp data=Content-type: application/x-www-form-urlencoded; charset=windows-1252 Content-Length: 68 Search=Product&LangIDCODE=20%3Ben-us&Value=0&OpSysID=9800&Show=Alpha 1024[807f158]: Assertion: "insufficient close container calls" (mStackPos == 1) at file nsHTMLContentSink.cpp, line 1563 Assertion: "insufficient close container calls" (mStackPos == 1) at file nsHTMLContentSink.cpp, line 1563 1024[807f158]: Break: at file nsHTMLContentSink.cpp, line 1563 Break: at file nsHTMLContentSink.cpp, line 1563

Buggy error handling caused us to hit the assertion. FIXED the problem.

To clarify, my understanding is that this issue is a problem on the webmaster's end, of using jscript that makes proprietary/non-standard DOM calls which we don't support, and that aspect of the bug is a clear WONTFIX. *But*, even so, our browser shouldn't be making the assertion noted by pollmann on 10.30.99, right? If that's the case, this bug is verified/fixed 1999 11.18 8:00 AM builds on Win32 & Linux.