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)
Tracking
()
RESOLVED
FIXED
mozilla1.0
People
(Reporter: tsipple, Assigned: harishd)
References
()
Details
(Keywords: ecommerce, regression)
Attachments
(8 files)
110.93 KB,
image/jpeg
|
Details | |
106.05 KB,
image/jpeg
|
Details | |
113.42 KB,
text/html
|
Details | |
74.32 KB,
text/html
|
Details | |
1.25 KB,
text/html
|
Details | |
356 bytes,
text/html
|
Details | |
372 bytes,
text/html
|
Details | |
2.13 KB,
patch
|
hjtoi-bugzilla
:
review+
jst
:
superreview+
dbaron
:
approval+
|
Details | Diff | Splinter Review |
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).
Reporter | ||
Comment 1•22 years ago
|
||
Reporter | ||
Comment 2•22 years ago
|
||
Reporter | ||
Comment 3•22 years ago
|
||
Reporter | ||
Comment 4•22 years ago
|
||
Comment 6•22 years ago
|
||
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...
Comment 7•22 years ago
|
||
This did not occur in 6.2 RTM... regression
Keywords: regression
Priority: -- → P2
Comment 8•22 years ago
|
||
need build number where regression was observed. thx (on the schedule)
Updated•22 years ago
|
Comment 9•22 years ago
|
||
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
Comment 10•22 years ago
|
||
The last build I could find that doesnt have this problem is 2001-12-03-08-trunk on linux.
Comment 11•22 years ago
|
||
What's the earliest build that you tried that does have it?
Comment 12•22 years ago
|
||
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
Comment 13•22 years ago
|
||
*** Bug 130195 has been marked as a duplicate of this bug. ***
Comment 14•22 years ago
|
||
*** Bug 130645 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Assignee | ||
Comment 15•22 years ago
|
||
Assignee | ||
Comment 16•22 years ago
|
||
Assignee | ||
Comment 17•22 years ago
|
||
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.
Comment 19•22 years ago
|
||
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.
Assignee | ||
Comment 20•22 years ago
|
||
-->Bob Clary
Comment 21•22 years ago
|
||
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.
Updated•22 years ago
|
Component: African → US Ecommerce
Let's hope this will finally go to the correct people...
Assignee: harishd → aruner
QA Contact: moied → bclary
Reporter | ||
Comment 23•22 years ago
|
||
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?
Assignee | ||
Comment 24•22 years ago
|
||
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
Assignee | ||
Comment 25•22 years ago
|
||
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.
Assignee | ||
Comment 26•22 years ago
|
||
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 r=heikki
Attachment #75047 -
Flags: review+
Comment 29•22 years ago
|
||
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+
Assignee | ||
Comment 31•22 years ago
|
||
FIXED.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 32•22 years ago
|
||
*** Bug 131198 has been marked as a duplicate of this bug. ***
Comment 33•22 years ago
|
||
*** 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.
Description
•