1. from menu select tasks->privacy->form-manager->interview 2. fill in last name 3. from context menu select Save-Form-Data 4. go to www.cisco.com 5. click on "ordering online" 6. click on "purchase Cisco logo merchandise" 7. click on "apparel" 8. click on any picture 9. fill in a quantity and click on "add to cart" 10. click on checkout 11. right-click on "prefill form" At this point the name field should get filled in. Instead you get the message saying "There are no fields that can be prefilled"
Problem is that the checkout page was arrived at via a redirect. Although the location bar lists the final page correctly as www1.ecorpstore.com/consumer/cisco/pay.asp However a call to the following function shell->GetDocument(getter_AddRefs(doc)); // in WLLT_Prefill url = doc->GetDocumentURL(); // in wallet_InitializeCurrentURL url->GetHost(&host); // in wallet_GetHostFile returns the following page www1.ecorpstore.com/consumer/cisco//display-item.asp A look at the network traffic shows that this page was indeed fetched and it contained a redirect to the eventual page. The wallet code makes the above call to determine the current page and uses it to see if it has any fieldschema information for that page in its tables. The wallet tables contain the final url and the the source of the redirect. So no match is found and wallet is unable to properly identify the fields on this form.
Status: NEW → ASSIGNED
Target Milestone: --- → M18
An easier way to demonstrate this problem is to print out the current url from an OnEndDocumentLoad handler. There is such a handler in extensions/wallet/src/nsWalletService.cpp. That handler contains, in essense, the following code to obtain the url rv = docViewer->GetDocument(*getter_AddRefs(doc)); docURL = doc->GetDocumentURL(); (void)docURL->GetSpec(&spec); So immediately after the above line add: printf("\n@@@ @@@ spec=%s\n", spec); Now the url will be printed out after each page is finished loading. From the generated output it will be seen that the url of the last page loaded is that of the initial request and not of the target of the redirect.
Just filed bug 49552 regarding the problem of obtaining the correct url after a redirect occurs. That bug is blocking this bug from being fixed.
Depends on: 49552
Here's a flaw in our bug-tracking system. I mark this bug as being blocked by bug 49952. Then gagan dups bug 49552 to bug 48200. That causes the dependency line in this bug to have a slash through 49552 which would give someone the impression that the blockage has been fixed when indeed that is not the case. Adding bug 48200 to the depends-on line.
Depends on: 48200
The duplicate bug flaw is reported as bug 9403 (and not looking very active).
Gagan just fixed bug 48200. And with that bug fixed, this bug no longer occurs.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
argh. i cannot seem to verify this because after i click the Checkout button, i get a timeout error ("operation timed out trying to reach www1.ecorpstore.com"). tested using opt comm bits on winnt and linux, 2000.09.05.04. also get this mesg in the console when clicking the Checkout button: Error loading URL http://www1.ecorpstore.com/consumer/cisco//display-item.asp?path=Cisco%2EGift+Shop%2Eapparel&pid=CS%2D300%2DTEMPLATE&prevTime=2&pageState=submission: 804b0002 anyone else able to vrfy?
Status: RESOLVED → VERIFIED
finally works for me now. vrfy 2000.09.15.08/9 on linux, mac and winnt [opt comm].
Assignee: morse → nobody
Component: Form Manager → Form Manager
Product: Core → Toolkit
QA Contact: bugzilla → form.manager
Target Milestone: M18 → ---
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.