Autofill doesn't work on cisco forms




19 years ago
11 years ago


(Reporter: morse, Unassigned)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta3+], URL)



19 years ago
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
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

19 years ago
Problem is that the checkout page was arrived at via a redirect.  Although the 
location bar lists the final page correctly as

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

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 
Keywords: nsbeta3
Target Milestone: --- → M18

Comment 2

19 years ago
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();

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

19 years ago
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

Comment 4

19 years ago
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).
Whiteboard: [nsbeta3+]

Comment 6

19 years ago
Gagan just fixed bug 48200.  And with that bug fixed, this bug no longer occurs.
Last Resolved: 19 years ago
Resolution: --- → FIXED
Keywords: verifyme
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").
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

anyone else able to vrfy?
Keywords: verifyme
finally works for me now. vrfy 2000.09.15.08/9 on linux, mac and winnt [opt
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.