49547 - Autofill doesn't work on cisco forms

Status: VERIFIED FIXED

(Toolkit :: Form Manager, defect, P3)

Description

[Stephen P. Morse]

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"

Comment 1

[Stephen P. Morse]

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.

Comment 2

[Stephen P. Morse]

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.

Comment 3

[Stephen P. Morse]

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.

Comment 4

[Stephen P. Morse]

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.

Comment 5

[Daniel Veditz [:dveditz]]

The duplicate bug flaw is reported as bug 9403 (and not looking very active).

Comment 6

[Stephen P. Morse]

Gagan just fixed bug 48200.  And with that bug fixed, this bug no longer occurs.

Comment 7

[sairuh (rarely reading bugmail)]

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?

Comment 8

[sairuh (rarely reading bugmail)]

finally works for me now. vrfy 2000.09.15.08/9 on linux, mac and winnt [opt
comm].