Closed
Bug 57838
Opened 24 years ago
Closed 24 years ago
cannot purchase a ticket through Netcenter WebTravel
Categories
(Core :: Layout: Form Controls, defect, P1)
Core
Layout: Form Controls
Tracking
()
People
(Reporter: buster, Assigned: pollmann)
References
()
Details
(Whiteboard: [rtm need info])
Attachments
(3 files)
1. Load home.netscape.com
2. Click on "Book your flight" link, takes you to
http://webcenter.travel.netscape.com/travel/index.jsp
3. go through the steps to book a flight. eventually you'll get to a screen that
shows a particular flight with a "Buy Now" button.
4. log in when asked, or create a new profile if necessary
5. agree to the fare on the next page
6. click "continue" on the next page
7. Click "information is correct" on the "Complete the passenger information
" page
8. Finally, you're at the page that causes the problem,
https://webcenter.travelocity.netscape.com:443/airgseatmapdisp.ctl?SEQ=97241236626332910242000&LANG=EN
I'll attach this page, though I don't know if it's of any use in isolation. This
page has the title "Enter billing and delivery information"
9. enter credit card info, billing address, and delivery address.
10. click "continue" *WARNING* Don't do this unless you really want to buy the
ticket! Someone at netcenter should set up a dummy account where the credit
card isn't billed, if the bug can't be fixed with just the source from the page.
11. You'll get a pop-up window that says the State/Province has an illegal
value. This is impossible since it's a drop-down, and "CA-California" is selected.
12. You're stuck. You can't proceed no matter what you try.
this seems like a critical blocker to me. either NS6 needs to handle form
submission on our own website, or the Netcenter folks need to fix the page. The
bug needs immediate investigation to determine where the error lies, in the
browser or the website.
Keywords: rtm
Priority: P3 → P1
I should have mentioned, this works fine in NS 4.x
Keywords: 4xp
Updated•24 years ago
|
QA Contact: vladimire → chrisd
Comment 4•24 years ago
|
||
I have tested the attached page and I cannot see where anything is going wrong.
I have verified that it submits what Nav 4.x submits (as far as State/Providence
goes) I even put some debug statements in the state verify code and can't see
anything. I think we will need to get Netcenter's help with this.
Comment 5•24 years ago
|
||
Assignee | ||
Comment 8•24 years ago
|
||
If I had to guess, I'd say this was bug 27006. The classic requirements are:
Form method=post
Resulting page contains:
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
Classic symptoms are:
Submit the form.
Server side complains about "missing fields" or otherwise looks as if form
submit fails -BUT- the submit actually was sent correctly (i.e. you probably
bought your ticket), then REsubmitted incorrectly (missing input fields) -
showing only the results of the second submission.
Steve, you might want to check if you actually bought the ticket or not... :S
Status: NEW → ASSIGNED
Assignee | ||
Comment 9•24 years ago
|
||
FWIW, there is a server-side fix for this problem as well - remove the <meta...
line. That would fix Netcenter, but leave any other commercial site with this
problem vulnerable.
Comment 10•24 years ago
|
||
Sent email to Kimberly Lau, Netcenter, informing her of the problem.
Comment 11•24 years ago
|
||
Eric P: Please explain further the "downside" of the server side fix. What do
you mean by "vulnerable?"
Assignee | ||
Comment 12•24 years ago
|
||
Perhaps vulnerable was a bad word choice. Nothing intentionally malicious is
occuring here.
I'm going on the assumption that this is actually bug 27006, but can not be
certain of this unless I receive a test account from Netcenter to debug with.
(Or Netscape is willing to pay for a few airline tickets! ;) )
The downside of not fixing 27006 but instead using a server side fix for this
bug is that in this particular test case, a financial transaction may have
occured that the user was not aware of (Steve's purchase of the ticket may have
happened but the response he was was essentially "Transaction failed".)
Other websites may be vulnerable in the sense that it is very easy to create the
scenario required to encounter bug 27006 unintentionally, and as a result, your
users may accidentally purchase things without being aware that they are doing so.
Assignee | ||
Comment 13•24 years ago
|
||
oops, s/response he was was/response he saw was/g;
Assignee | ||
Comment 15•24 years ago
|
||
Well I've been playing around with Netcenter Travel some, and I have to say that
it's not entirely clear to me any more that this is in fact a duplicate of bug
27006. I'd still say 27006 is a likely culprit, but my confidence factor is not
as high. :s My reasons for doubt are:
1) I'm not even sure this bug is reproducible in today's build. I tried putting
plane tickets on hold (rather than buying), and was able to do that with no
problems. The hold page looks an awful lot like the buy page.
2) I was playing around with <meta> tags with a charset specified. When the
charset is iso-8859-1, this is the same as the default charset for Windows and
Linux - and won't cause a reload. Again, I have not ever seen the results page
from purchasing plane tickets, so who knows what's there. But if it is a <meta>
with a charset specified, and that charset is iso-8859-1, this may not be bug 27006
At any rate, I still think 27006 is is a really serious bug, and could cause
problems like this.
I've contacted Kimberly Lau in Netcenter to try to get either a demo account or
some time talking with someone on Netscape Travel's server side. Hopefully
getting one of those will allow me to figure out what is really going on with
this bug - and if it is indeed the same as 27006.
Assignee | ||
Comment 16•24 years ago
|
||
Kristina Dupuis has provided me with some test account information. USing this
I've already been able to rule out this being a dup of 27006. The popup buster
described looks like a javascript popup. Will keep looking at this!
No longer depends on: 27006
Assignee | ||
Comment 17•24 years ago
|
||
This is actually a small but in the select widget code. There are two options
selected in the HTML for the state selection dropdown. This causes us to select
two options in the widget (should only allow one). Then, later when javscript
verifies the form, it finds selectedIndex for the select is 0 (the first
selected option).
This can be fixed on the server side by only selecting one option in the HTML
This can be worked around by the user by selecting the first option, then
selecting another option.
There is probably a duplicate bug around - Rod might have it, I'll search...
Component: Form Submission → HTML Form Controls
OS: Windows NT → All
Hardware: PC → All
Assignee | ||
Comment 18•24 years ago
|
||
argh... "This is actually a small bug" hehe. ;)
Assignee | ||
Comment 19•24 years ago
|
||
The existing report is bug 53457. Rod has a fix for this bug. Also, there is a
server side fix mentioned above. I'll send off an email to Kristina detailing
how to fix the problem from the server side.
Since this isn't a dup of 27006, and there was no chance of an accidental
transaction occuring here, I don't know if there is any pressing need to make
sure this makes it in for RTM.
*** This bug has been marked as a duplicate of 53457 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Comment 20•24 years ago
|
||
Comment 21•24 years ago
|
||
thank you, Eric, for tracking this down! If you are able to get Netcenter to
correct this, please post the status here. Thanks.
Assignee | ||
Comment 22•24 years ago
|
||
I received an email from Kristina. She contacted Travelocity to get the bug
fixed on their end. Here is the message they returned:
========================================================
I have removed the second "N/A" from the list. This should be in for the Nov 10
implementation.
Let me know if you come across any other HTML issues with Netscape 6. Even if
they are not related to Travelocity.com. We can try to be proactive about our
programming if we are aware of any issues.
========================================================
I'll attempt to purchase a ticket using the demo account information, and verify
that the bug is fixed on Nov. 10.
Comment 23•24 years ago
|
||
Per Eric's comments, verified bug a dup of #53457.
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 24•24 years ago
|
||
I tested this today and was successfully able to purchase a ticket with the test
account information. I have a confirmation number and everything. :) Cool!
You need to log in
before you can comment on or make changes to this bug.
Description
•