Results not displayed when searching

VERIFIED FIXED in M12

Status

()

Core
HTML: Form Submission
P3
normal
VERIFIED FIXED
19 years ago
10 months ago

People

(Reporter: mats, Assigned: harishd)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: help wanted, URL)

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
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.

Updated

19 years ago
Assignee: karnaze → kmcclusk

Comment 1

19 years ago
Reassigning to Kevin

Updated

19 years ago
Assignee: kmcclusk → gagan
Component: Form Submission → Necko
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.

Updated

19 years ago
Target Milestone: M10

Updated

19 years ago
Status: NEW → ASSIGNED
Whiteboard: help wanted
Target Milestone: M10 → M12

Comment 3

19 years ago
any volunteers to watch the HTTP traffic and see the difference?

Comment 4

19 years ago
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.

Comment 5

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

Comment 6

18 years ago
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...

Comment 7

18 years ago
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.

Updated

18 years ago
Assignee: gagan → pollmann
Status: ASSIGNED → NEW
Component: Necko → Form Submission
OS: Windows 98 → All
Hardware: PC → All

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 8

18 years ago
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'...

Comment 9

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

Comment 10

18 years ago
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.  :)

Updated

18 years ago
Blocks: 16950

Comment 11

18 years ago
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?

Comment 12

18 years ago
Created attachment 2420 [details]
Log of HTTP response activity for the POST

Updated

18 years ago
Assignee: pollmann → harishd
Status: ASSIGNED → NEW

Comment 13

18 years ago
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

Updated

18 years ago
Blocks: 17907
(Assignee)

Updated

18 years ago
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 14

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

Updated

18 years ago
Status: RESOLVED → VERIFIED
QA Contact: cpratt → elig

Comment 15

18 years ago
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.

Updated

18 years ago
No longer blocks: 17907
You need to log in before you can comment on or make changes to this bug.