Closed
Bug 57333
Opened 24 years ago
Closed 24 years ago
A FORM on Yahoo! will not submit with Mozilla
Categories
(Core :: DOM: Core & HTML, defect, P1)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
FIXED
People
(Reporter: stephe, Assigned: pollmann)
References
()
Details
(Keywords: top100, Whiteboard: [rtm++]fix in hand)
Attachments
(5 files)
383 bytes,
text/html
|
Details | |
491 bytes,
text/html
|
Details | |
2.51 KB,
patch
|
Details | Diff | Splinter Review | |
1.07 KB,
text/html
|
Details | |
2.22 KB,
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•24 years ago
|
||
Comment 2•24 years ago
|
||
Confirmed on Linux RH 6.2 2000101911
Comment 3•24 years ago
|
||
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?
Comment 4•24 years ago
|
||
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.
Comment 5•24 years ago
|
||
accepting, looking into it
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Comment 6•24 years ago
|
||
Comment 7•24 years ago
|
||
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?
Comment 8•24 years ago
|
||
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)
Comment 9•24 years ago
|
||
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.
Keywords: evangwanted
Assignee | ||
Comment 10•24 years ago
|
||
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.
Assignee | ||
Comment 11•24 years ago
|
||
(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.)
Comment 12•24 years ago
|
||
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.
Keywords: rtm
Priority: P3 → P1
Assignee | ||
Comment 13•24 years ago
|
||
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...
Assignee | ||
Comment 14•24 years ago
|
||
Assignee | ||
Updated•24 years ago
|
Whiteboard: fix in hand
Comment 15•24 years ago
|
||
Marking [rtm need info]
Whiteboard: fix in hand → [rtm need info]fix in hand
Assignee | ||
Comment 16•24 years ago
|
||
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)
Assignee | ||
Comment 17•24 years ago
|
||
Comment 18•24 years ago
|
||
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
Assignee | ||
Comment 19•24 years ago
|
||
Assignee | ||
Comment 20•24 years ago
|
||
Updating platform, reassigning.
Assignee: rods → pollmann
Status: ASSIGNED → NEW
OS: Windows NT → All
Hardware: PC → All
Comment 21•24 years ago
|
||
This lastest patch looks great, this really needs needs to go into the
trunk AND branch
r=rods
Comment 22•24 years ago
|
||
sr=vidur
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Whiteboard: [rtm need info]fix in hand → [rtm+]fix in hand
Comment 23•24 years ago
|
||
Did a second review and it ( patch ) looks fine.
r=harishd
Assignee | ||
Comment 25•24 years ago
|
||
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.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 26•24 years ago
|
||
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
Status: RESOLVED → VERIFIED
Updated•24 years ago
|
Keywords: evangwanted
Updated•6 years ago
|
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•