52119 - [nsbeta3+][FIX]Link processing does not properly remove the CR/LF from the url in the anchor

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P1)

Description

[ckritzer (gone)]

Overview:  While regressing bug#43643, I discovered that form submission seems 
to be garbling info in the form and therefor not returning the correct 
information to the user.

Steps to reproduce:
1) Goto 
http://www.rent.net/ctg/cgi-bin/RentNet/AptRentalStates/AAAAfNAAXAAAKy7AAk/?bran
2) Click on *any* of the listed states

Actual Results:  You will get a page which says "Welcome to ."  "0 city 
found..."  with NO listing of all the cities which contain rental units.

Expected Results:  A listing of all the cities which contain renta units.

Platforms tested:
- LinuxRH62 2000-09-08-08-M18 Commercial
- Win98     2000-09-08-08-M18 Mozilla
- MacOS86   2000-09-07-04-M18 Commercial

Blocks: Bug#43643

Comment 1

[Jeffrey Baker]

I'm seeing this on Linux, and I filed bug 52030 against it.

Comment 2

[rods (gone)]

When I click on the link in the attached example, Moz is not properly removing 
the CR/LF from the url in the anchor.

With Moz: 
http://pollmann.net/echo.cgi?stateID=%0D%0AAL1&countryID=USA%0D%0A&stateAbbr=AL&
fromPage=aptState

With Nav 4.x:
http://pollmann.net/echo.cgi?stateID=AL1&countryID=USA&stateAbbr=AL&fromPage=apt
State

Comment 3

[rods (gone)]

Attachment: reduced testcase

Comment 4

[rods (gone)]

In the constructor of nsHTTPChannel line 114:

    mURI->GetSpec(getter_Copies(urlCString));

This method calls GetSpec which calls GetPath whcih calls AppendString with 
ESCAPED:

    if (mQuery)
    {
        path += '?';
        rv = AppendString(path,mQuery,ESCAPED,nsIIOService::url_Query);
        if (NS_FAILED(rv))
            return rv;
    }
This is where the they get improperly converted.


Here is the call stack that led up to the call:

nsStdURL::GetPath(nsStdURL * const 0x028eca70, char * * 0x0012fac0) line 804 + 
26 bytes
nsStdURL::GetSpec(nsStdURL * const 0x028eca70, char * * 0x0012fb00) line 453 + 
16 bytes
nsHTTPChannel::nsHTTPChannel(nsIURI * 0x028eca70, nsHTTPHandler * 0x015a34e0) 
line 117
nsHTTPHandler::NewChannel(nsHTTPHandler * const 0x015a34e0, nsIURI * 0x028eca70, 
nsIChannel * * 0x0012fc28) line 243 + 38 bytes
nsIOService::NewChannelFromURI(nsIOService * const 0x0155b1b0, nsIURI * 
0x028eca70, nsIChannel * * 0x0012fc28) line 294 + 31 bytes
NS_OpenURI(nsIChannel * * 0x0012fd4c, nsIURI * 0x028eca70, nsIIOService * 
0x0155b1b0, nsILoadGroup * 0x0152ee40, nsIInterfaceRequestor * 0x0153f0a4, 
unsigned int 0, unsigned int 0, unsigned int 0) line 105 + 20 bytes
nsDocShell::DoURILoad(nsDocShell * const 0x0153f080, nsIURI * 0x028eca70, nsIURI 
* 0x028c06c0, nsISupports * 0x00000000, int 1, int 1, const char * 0x0012fe24, 
nsIInputStream * 0x00000000, nsIInputStream * 0x00000000) line 3131 + 90 bytes
nsDocShell::InternalLoad(nsDocShell * const 0x0153f080, nsIURI * 0x028eca70, 
nsIURI * 0x028c06c0, nsISupports * 0x00000000, int 1, int 0, const char * 
0x0012fe24, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000, int 7, 
nsISHEntry * 0x00000000) line 2833 + 47 bytes
nsWebShell::HandleLinkClickEvent(nsIContent * 0x028ed370, nsLinkVerb 
eLinkVerb_Replace, const unsigned short * 0x028ec700, const unsigned short * 
0x002d55e8 gCommonEmptyBuffer, nsIInputStream * 0x00000000, nsIInputStream * 
0x00000000) line 858
OnLinkClickEvent::HandleEvent() line 735
HandlePLEvent(OnLinkClickEvent * 0x028eb5a0) line 749
PL_HandleEvent(PLEvent * 0x028eb5a0) line 589 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x0153e180) line 526 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00020d06, unsigned int 49423, unsigned int 0, 
long 22274432) line 1059 + 9 bytes
USER32! 77e71820()
0153e180()

Comment 5

[rods (gone)]

This seems bad enough to nominate. reassigning

Comment 6

[rods (gone)]

maybe this isn't gagan's issue and the real problem is the CF/LF need to be 
stripped by the content sink.

Comment 7

[rods (gone)]

I think the bug is at a much higher level, therefore it is not gagan's bug. It 
needs to be fixed either in nsHTMLGenericElement or in the content sink.

Comment 8

[rods (gone)]

I have a fix, it may not be the best, but it works. It still seems it should be 
taken care of elsewhere, but I strip out CF & LF in:
nsGenericHTMLElement::HandleDOMEventForAnchors

Comment 9

[Kevin McCluskey (gone)]

Marking nsbeta3+.

Comment 10

[rods (gone)]

fixed

Comment 11

[Vladimir Ermakov]

Dont see the problem any more. Marking verified.

Comment 12

[Vladimir Ermakov]

Dont see the problem any more. Marking verified.

Comment 13

[Vladimir Ermakov]

Cant see the problem any more. Marking verified.