At the above URL on Yahoo!, you will find a form for submitting your zip code called "Get Local". Enter a zip code and click on the "Get Local" button. The submitted URL looks like http://search.local.yahoo.com/zipsearch?q=&q=94720 and Yahoo! displays a page saying "Bad or invalid zipcode: "q=&q=?". Please try again." This form works fine in NN4 and IE5. The form looks like: <form method=get action="http://search.local.yahoo.com/zipsearch?q="> <p> Enter your zip code: <br> <input name=q type=text size=7 maxlength=7> <input type=submit value="Get Local"> </form> The problem seems to be the "q=" on the end of the action URL. With that removed, Mozilla submits the form ok. I have attached an HTML page that contains just this form. Tested with Mozilla 101820 trunk build on NT4.

Confirmed on Linux RH 6.2 2000101911

I don't know what Netscape 4.x is doing with that form, but Mozilla seems to be doing exactly what it would be expected to do given the value of the ACTION attribute and the contents of the form. This looks like a bug in Yahoo's code to me. Should this be an Evangelism bug?

On N4.7 and IE5 just the value is appended to the end of that string so get http://search.local.yahoo.com/zipsearch?q=94720 On Netscape6 q= is ignored and &q=94720 is added after it. http://search.local.yahoo.com/zipsearch?q=&q=94720 I dont know if its a bug, but I think this should be changed for backward compatibility.

accepting, looking into it

What is the spirit of NavQuirks? On the page the action is: action="http://search.local.yahoo.com/zipsearch?q=" So when moz does the submit it end up doing: http://search.local.yahoo.com/zipsearch?q=&q=57049 So apparently 4.x & IE strip away the original "q=" and moz doesn't, so it doesn't work. It looks like we should be stripping this away also. I don't know how validation is down to see if the "q=" to see if "q" is actually in the form or not. probably none, I just put in "x=" and it still stripped it. This is a bug with Yahoo, a top100 site, Eric K. should I fix this?

It looks like we could strip it in nsFormFrame::OnSubmit right after we get the "href" variable from the GetAction call Eric P. what do you think? (Around line 733)

Marek, could someone from sustaining please advise us what algorithm Nav4 used to correct this kind of bogus GET submission in which there were some fields like "q=" that didn't have values and duplicated another field? Questions: 1) Are all fields without values stripped out? (e.g. strip out anything that ends in =) 2) Or does it check for duplicate entries and only strip out duplicates that end in =? Adding evangwanted; please evangelize Yahoo to fix their code to eliminate these bogus entries that have no value and are duplicates.

This is the third part of bug 23376 and bug 25330. I think I chose Opera's behaviour, but if both IE and Nav do the same thing, that was obviously the wrong decision. This would probably be a one or two line fix. Rod, I think you're looking at the right code, and in fact, this string operation is already done for form post's with no specified action at line 772. If we moved that chunk of code down to line 810, no new code would need to be added.

(The reason I chose Opera's behaviour was that it seemed more in keeping with a literal interpretation of the spec. I could be reading the spec wrong , or reading too far into it. Regardless, given the current market situation, I'd say we should fix this behaviour to be like Nav and IE.)

Yes. For this kind of thing (graceful handling of poor input) being backwardly compatible is the crucial thing. We all know that there's no market demand for us to gratuitously break sites in situations like this. ;-> And yes, going with the Nav4/IE interpretation here is wiser than going with Opera's. Nominating for rtm consideration. Setting P1. High profile site, high profile backward compatibility. Appears that fix is well defined and will be very low risk.

Okay, the fix isn't quite as simple as just moving that chunck of code down - that could reopen some edge cases relateing to bug 42616. I think I have a fix that handles that too - will post after some quick testing...

Marking [rtm need info]

I've verified that the patch fixes this test case (both the reduced and the original page), and does not break any of the previous related bugs. I'll also include an additional test case to play with that tests method="POST" and with and without named anchors. Every one now works like IE and Nav (before this fix, some scary things happen)

I just tested the lastest patch AND ran through it in the debugger. The fix it's self is pretty low risk. It merely truncates everything from the "?" on (including the "?") then later builds up the appropriate string. I think this is low risk for high return. r=rods

Updating platform, reassigning.

This lastest patch looks great, this really needs needs to go into the trunk AND branch r=rods

sr=vidur

Did a second review and it ( patch ) looks fine. r=harishd

rtm++

Fix checked in to tip and branch. To verify: Go the the attachment marked "reduced testcase". Enter your zip and submit form. You should see a regional page for your area, not an error page.

verifying on -Windows98 build 2000-10-24-09-MN6 -branch 2000-19-25-08-Mtrunk -Linux RedHat6.2 build 2000-10-24-09-MN6 2000-10-25-08-Mtrunk