Closed Bug 128521 Opened 22 years ago Closed 22 years ago

Form Submission on Hotwire Results in Wrong Hotel Room!

Categories

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

Other
All
defect

Tracking

()

RESOLVED FIXED
mozilla1.0

People

(Reporter: tsipple, Assigned: harishd)

References

()

Details

(Keywords: ecommerce, regression)

Attachments

(8 files)

This bug is 100% reproducible in both Windows and OS/2 builds so far, so it
seems to be easily recreated.  Here's one recreation scenario we know is broke.
 Due to possible changes in Hotwire web site, suggest recreating ASAP.

1.  Go to http://www.hotwire.com
2.  Click on Hotels radio button
3.  From the City pulldown, select St. Louis, MO
4.  Select check-in date of March 6 and checkout date of March 7
5.  Leave Number of rooms at 1
6.  Click Start
7.  Check the Downtown checkbox and click Continue
[Logon to Hotwire omitted here.  You will need to create a free account.]
8.  There should be three offerings displayed (4 star, 3.5 star, 3 star).  Click
on Continue button next to 3.5 star hotel.

Result: Four star hotel is displayed in the left margin on credit card entry
form.  Hotwire thinks four star hotel was selected.

Bug does not occur in Netscape 4.61 for OS/2 Warp or Microsoft Internet Explorer
5.0 for Windows.  Bug has been replicated on two platforms on two different
systems with Mozilla, including OS/2 build 2002022108 and latest Windows nightly.

Bug classified as "blocker" because of obvious peril for e-commerce.  (It
certainly bit me.  I booked a room at 2.5 times the price!  :-))

Four file attachments: results.jpg (page with the three offers listed),
billing.jsp (page after clicking the second offer button, with the incorrect
hotel), and corresponding page source (results.jsp and billing.jsp).
Attached file results.jsp
Attached file billing.jsp
This is a REALLY bad bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file Minimised Testcase
This is a mimimised testcase of the problem. To test you have to login to
HotWire first

Email: vladimire@netscape.com
Pass: mozilla

Basicly the problem is that in the sidebar there is a form that doesnt have a
</form> tag, and that is causing the wrong data to submit...
This did not occur in 6.2 RTM... regression
Keywords: regression
Priority: -- → P2
need build number where regression was observed.

thx
(on the schedule)
Keywords: nsbeta1
Priority: P2 → P1
Target Milestone: --- → mozilla1.0
Bulk moving all nsbeta1 nominations to future-P1. If they are approved
(nsbeta1+) they will be moved to mozilla1.0
Target Milestone: mozilla1.0 → Future
The last build I could find that doesnt have this problem is 2001-12-03-08-trunk
on linux. 
What's the earliest build that you tried that does have it?
Ok, I think this must go to the parser cause with the minimised testcase
(attachment 72450 [details]) when dumping the content you get to see only one form frame
instead of three.

Unfortunately this crappy HTML works in IE so I think that it should somehow
work in Mozilla too.

I this is not parser, reassign to the proper component or back to me (maybe is a
CSSFrameContructor problem, but I doubt that).

Assignee: alexsavulov → harishd
Component: Form Submission → Parser
QA Contact: vladimire → moied
*** Bug 130195 has been marked as a duplicate of this bug. ***
*** Bug 130645 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1nsbeta1+
Target Milestone: Future → mozilla1.0
Attached file Testcase
The fix to this bug is back out changes that fixed bug 96861. However, with the
fix for bug 96861 we do handle incorrect mark up correctly and as expected.
Here is an example that would explain what will happen with and without the fix
for bug 96861:
1. <FORM method="POST" action="www.example1.com/cgi-bin/blah">  
2.  <FORM> <!-- INCORRECT HTML. SINCE, FORMS CANNOT NEST -->
3.  </FORM>
4.  <INPUT type = "submit">
5. </FORM> 

Without the fix
----------------
</FORM>, in line 3, will close out <FORM> in line 1. That's, values will not be
submitted to www.example1.com/cgi-bin/blah.

With the fix
------------
</FORM>, in line 3, will couse out <FORM> in line 2 and </FORM> in line 5 will
close out <FORM> in line 1. That's, values will be submitted to
www.example1.com/cgi-bin/blah.

The question now is whether to support a fix that would handle cases as
expected, or the fix that would solve the problem described in this page.
I'm not sure which side to take :(. May be we should first try to evangelize the
site.

--> Evangelism
Component: Parser → African
Product: Browser → Tech Evangelism
Target Milestone: mozilla1.0 → ---
Version: other → unspecified
I strongly suggest this should be fixed by evangelizing broken sites. If we find
lots of broken sites I might reconsider. What IE and older Mozilla/Netscape
versions are doing is totally counterintuitive. The fix is simple on the content
side: just closing forms properly. 

If we back out the fix to bug 96861 we just make it hard to figure out what is
going on with pages that have forms.
I entered this bug and would like to ask that no issues that are based on 
people writing bad HTML get fixed.  I notified this site of their problem.  
People should stick to the spec and when it comes to HTML, it's not that hard.
-->Bob Clary
Just for kicks, here's their response:

Thank you for bringing this matter to our attention.  This 
incorrect positioning of form tags on the Chase Online Plus login 
page will be corrected during a system upgrade at a later time.  
If you require further assistance, please e-mail or contact our 
24-hour Internet Service Center at 1-877-CHASEPC (1-877-242-7372).

How long does it take to put in 2 </form> tags?

BTW: I'm really pleased with this release.
Component: African → US Ecommerce
Let's hope this will finally go to the correct people...
Assignee: harishd → aruner
QA Contact: moied → bclary
I agree it's bad HTML, and I do agree that it's OK for Mozilla to fail.  I don't
agree that it's OK for a Mozilla user to end up sending bad data to such a
miscoded site.  That's what's happening here.  Is there any way that problem can
be fixed so that Mozilla can fail gracefully on such pages?
IE & Nav4.x seem to handle this incorrect markup and so should Mozilla. Timothy
is right, this is a serious problem and, IMO, should be fixed. Taking bug back :-/
Assignee: aruner → harishd
Attached patch patch v1.1Splinter Review
This patch would regress bug 96861. However, fixing bug 128521 is more crucial
than fixing 96861. I'll try to come up with a new fix for bug 96861.
FYI: Have a fix in hand for bug 96861
Changing back to parser
Component: US Ecommerce → Parser
Product: Tech Evangelism → Browser
Target Milestone: --- → mozilla1.0
Version: unspecified → other
Comment on attachment 75047 [details] [diff] [review]
patch v1.1

sr=jst
Attachment #75047 - Flags: superreview+
Comment on attachment 75047 [details] [diff] [review]
patch v1.1

a=dbaron for trunk checkin
Attachment #75047 - Flags: approval+
FIXED.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 131198 has been marked as a duplicate of this bug. ***
*** Bug 123397 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: