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.

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.

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.

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.

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'.

OK, I'll remove the dependency on y:. This was just temporary anyhow, pending the availability of modal dialogs.

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. ***

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