Wallet - Safe Form Fill not working

VERIFIED FIXED

Status

()

Toolkit
Form Manager
P3
normal
VERIFIED FIXED
19 years ago
10 years ago

People

(Reporter: Paul MacQuiddy, Assigned: Stephen P. Morse)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 1

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

Updated

19 years ago
Status: RESOLVED → REOPENED
(Reporter)

Comment 2

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

Updated

19 years ago
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: FIXED → WORKSFORME
(Assignee)

Comment 3

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

Updated

19 years ago
Status: RESOLVED → REOPENED
OS: Windows 95 → All
Hardware: PC → All
(Reporter)

Comment 4

19 years ago
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'.
(Assignee)

Updated

19 years ago
Resolution: WORKSFORME → ---
(Assignee)

Comment 5

19 years ago
OK, I'll remove the dependency on y:.  This was just temporary anyhow, pending
the availability of modal dialogs.
(Assignee)

Updated

19 years ago
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 6

19 years ago
Dependency on y: is now removed.  This should now be working for everyone.
Marking as fixed.
(Assignee)

Comment 7

19 years ago
*** Bug 4746 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

19 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 8

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

Updated

10 years ago
Component: Form Manager → Form Manager
Product: Core → Toolkit
QA Contact: paulmac → form.manager
You need to log in before you can comment on or make changes to this bug.