Closed Bug 5137 Opened 25 years ago Closed 25 years ago

Wallet - Safe Form Fill not working

Categories

(Toolkit :: Form Manager, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: paulmac, Assigned: morse)

References

Details

Using 4/14 M4 builds on Windows 95.

Description: The Safe Form Fill feature does not seem to be working. The only
thing that happens when I select it is an empty, hung, new browser window is
opened.

To reproduce:

1. Select Edit - Wallet - Samples - HERE and fill in some data such as First and
Last Name and hit save.

2. Go back to the Samples Page

3. Choose any of the sample pages, then Edit - Wallet - Samples - Safe Form Fill

Expected Results:

I assume the form should get auto-filled where the data is available, though I
don't know the difference between the Safe and Quick Fill.

Note: The Quick Form Fill feature is working on the sample pages.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
This works fine for me.  I'm using a tree that I pulled on April 16.  What is
supposed to happen currently is that a new browser window opens with a listing
of those fields that it can fill in along with the values for those fields.
Upon hitting the OK button, those values get inserted into the form in the
original window.  What is really supposed to happen (once modal html dialogs is
implemented) is that the new window should disappear when the OK (or Cancel)
button is pressed but that doesn't happen in the current ad-hoc implementation
of html dialogs.

There was a bug here, however. If you set your preferences to not accept
cookies, pressing the OK button will cause a gp trap.  That's because this
ad-hoc implementation uses cookies to communicate with the html dialog.  I just
checked in a fix for that into extensions/wallet/src/htmldlgs.h

Marking this bug as fixed rather than "works-for-me" since I did make a source
change based on the crash that I observed when I tested out this bug.
Status: RESOLVED → REOPENED
Steve, are there any preferences you need to set to make this work? This still
only opens up a non-responsive browser window on 4/20 Windows builds. On Unix,
nothing happens. Re-opening bug for clarification.
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: FIXED → WORKSFORME
This is working with a tree that I just pulled but was not working with a tree I
pulled three days ago.  Marking as works-for-me.
Status: RESOLVED → REOPENED
OS: Windows 95 → All
Hardware: PC → All
Okay, confirmed that you need a y: virtual drive on your machine to make
anything work. Why didn't I think of that :-) This seems unacceptable - it
renders the Display Cookies, Display Signon, and Safefill menu items unusable
except to those using PC's and 'in the know'.
Resolution: WORKSFORME → ---
OK, I'll remove the dependency on y:.  This was just temporary anyhow, pending
the availability of modal dialogs.
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Dependency on y: is now removed.  This should now be working for everyone.
Marking as fixed.
*** Bug 4746 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
verified that the safe form fill now comes up without y: drive being needed.
Safe form fill still not working because of problems with the OK button, will
open a separate bug on this.
5/17 builds
Product: Core → Toolkit
QA Contact: paulmac → form.manager
You need to log in before you can comment on or make changes to this bug.