found this while trying to verify bug 26340. used opt comm build 2000.03.27.10 on macOS 9.0 --not repro on linux or winNT. 0. make sure you have a profile that has stored form data (go to Tasks > Personal Managers > Form Manager > View Stored Form Data to verify). trying to capture form data for this particular problem will only make you run into bug 28466. 1. go to the above URL, or any of steve's sample forms at http://www.mozilla.org/wallet/samples/ . 2. select Tasks > Personal Managers > Form Manager > Prefill Form Safely. if you get the dialog asking for your master passwd, enter it, then click OK. 3. get a dialog saying there are no fields to prefill.

*** Bug 33835 has been marked as a duplicate of this bug. ***

i now see this using winNT, comm bits 2000.05.03.08. removed pp keyword, and changed the OS to windowsNT (keeping platform set to Macintosh to remind me that's where i first saw this). encountered this while going through smoketest # B24, located at: http://www.mozilla.org/quality/smoketests/ scrolldown to see the steps to repro this on winNT.

This is working fine for me. Do you have the problem if you start with a fresh profile or only if you use an old existing profile? If it fails for old-profile only, then tell me what's on the first line in your xxx.w file. Of course you can't see the safe-form-fill dialog anymore. That's because of bug 37742.

doesn't fail w/old profile. fails using new profile (created using today's bits). another thing i noticed --and let me know if i should file a seperate bug on this-- is that (following the steps in the smoketest): * in my old profile, the first and last names were saved as variables with the labels "name.first" and "name.last". * in my new profile, the first and last names were saved as variables with labels beginning with "www.mozilla.org/wallet/samples/inte..." unfortunately, i cannot scroll to the right to get the full label name.

Putting on [nsbeta2+]. Does not need a fix ASAP for daily work per smoketest nominee, but we should fix this for beta2.

gah, this is no longer a problem --ie, using this afternoon's respun win32 comm bits (on winNT).

Sarah, please investigate further and find out what is going on. There were no changes made today that would account for this. Is this an intermittent problem, perhaps timing related?

Sarah, please confirm that (1) this is still a problem, and (2) it is cross platform. Thanks.

i'm able to prefill (ie, safely) the amazon.com form on mac (mozilla and commercial), linux (mozilla and commercial) and winNT (commercial). 2000.05.09.08.

very bizarre! after i got the hang from bug 38709, i now can hang the browser even when going to the amazon.com sample form (which has a single field that cat's multiple field values). i'm baffled.

another note: this recent problem occurred on linux (different session, too)

This is probably being caused by bug 22103.

Sarah, please try this out once again. Several things have changed recently that might affect this. For one, the prefill problem that started happening this week is now fixed so that should no longer get in the way here. For another, I changed the way I download the server tables and that might have been a factor. I'm anxiously awaiting your response. Do repeated testing on it because it seems to have been an intermittent failure in the past.

using opt commercial bits on linux, mac and winNT. 2000.05.12.08. 1. testing bug 28466, Capture Data from Form, starting with a new profile, eg, called "blah": a. winNT: works, but the field names are "www.mozilla.org/wallet/samples/inte..." b. linux and mac: fail. 2. testing bug 28466, Capture Data from Form, using an existing profile (namely "blah"): a. retested linux and mac: somehow managed to work! and as in (1a) with the long fieldnames. b. winNT retested (restarted the browser before this retest): works, but now this 2nd set of fieldnames are more reasonable, ie, "name.first," "name.last." 3. testing bug 33542, prefilling form w/stored data, using "blah": a. winNT: works, but data confirmation dialog only displays values captured from (2b). b. linux and mac: fails --prolly because of the fieldname issues from (2a).

Together with dp, I made some changes that eliminate the local thread that was used while the wallet tables were being downloaded. Also we now use local copies of the files if the download fails (that's what was causing the strange field names sairuh was reporting on in her last comment above). Marking as fixed and hoping that sairuh's verification on Monday will confirm that.

this is still a problem, using today's opt comm bits, 2000.05.17.16, with a new profile on winNT only. not a problem on an existing winNT profile, nor a new or existing profile on linux. with the new profile on winNT, as in previous failures noted above, captured the field names as "www.mozilla.org/wallet/samples/inte..."

Yep, I'm seeing this too. Doesn't seem to be intermittent either so I'm sure I'll be able to nip this one, once and for all.

Fix checked in. Changed file is wallet.cpp.

tested using opt comm bits 2000.05.22.08. still a problem using new profiles on winnt and mac. (unable to test w/new profile on linux due to bug 40211.) not a problem for existing profiles. same reason for failure: captured the field names as "www.mozilla.org/wallet/samples/inte..."

This is working for me. Sarah, can you check to see if you have the files URLFieldSchema.tbl, FieldSchema.tbl, and SchemaConcat.tbl in your resource directory. It gets put into the profile directory after using wallet, but it should exist in the resource directory from the time the browser is installed. If it's not there, it's a packaging problem and explains why it works fine for me on a build that I do myself whereas it fails if you use the packaged bits.

I believe the problem was an installer issue -- the wallet tables were indeed missing from the windows installer bits (although they were present in the installer bits for the other two platforms??). I just updated the installer package lists and hopefully that should fix the problem. So I'll mark this fixed once again and sarah will let me know if it is still a problem.

tried this using new profiles on winnt, linux (somehow managed to work w/a new profile, in spite of bug 40211, which has been dup'd of bug 34871, anyhow...), and Mac. results: * winNT and linux: pass. the fields have sensible names like name.first and name.last, and successfully prefill a form. * mac: fails. has the bad field names, and cannot prefill a form. thus, reopening. * on all 3: the *.tbl files do exist in the res/ dir. i'll check this out on existing profiles (will just quit and restart using the new one i just created), and add further comments in a bit...

capturing/prefilling works using existing profiles on the 3 platforms.

From the results that sarah just reported, this means that the code for accessing the resource directory does not work on the mac. Here is the code that I am using (in Wallet_ResourceDirectory in extensions/wallet/src/wallet.cpp: nsIFileSpec* spec = NS_LocateFileOrDirectory(nsSpecialFileSpec::App_ResDirectory); if (!spec) { return NS_ERROR_FAILURE; } nsresult res = spec->GetFileSpec(&dirSpec); NS_RELEASE(spec); return res; Robert, do you have the time to take a look at this? The bug report is complex so let me summarize the steps for demonstating it: 1. Start with fresh profile on the mac 2. Select any sample (menu: tasks->privacy->form-manager->demonstration) 3. Fill in any field 4. Capture form (menu: tasks->privacy->form-manager->capture) If you have a breakpoint set in the routine mentioned above, you should hit the breakpoint when you do step 4. If you now step through the routine, it is probably returning failure (I say that based on the symptoms sarah reported) but it shouldn't be.

Let's try verifying this one once again. Problem was in accessing the resource directory on the mac. But due to bug 41567, I just moved the wallet table files out of the resource directory and into the defaults directory. So that should fix this problem as well. Marking as fixed again and hoping it passes verification this time (I don't have a mac to test it on).

Oops, not fixed yet. My checkin broke the mac build so I had to back it out. Will need to look into it some more.

Fix checked in again. Give it a try sarah.

vrfy [using existing profiles] w/commercial trunk bits 2000.06.14.08-m17 on linux, Mac and winnt. whew!