Closed
Bug 33542
Opened 25 years ago
Closed 24 years ago
unable to Prefill Form Safely even when there's stored form data
Categories
(Toolkit :: Form Manager, defect, P3)
Tracking
()
VERIFIED
FIXED
People
(Reporter: bugzilla, Unassigned)
References
()
Details
(Keywords: smoketest, Whiteboard: [nsbeta2+])
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.
Updated•25 years ago
|
Target Milestone: --- → M16
Updated•25 years ago
|
Status: NEW → ASSIGNED
Reporter | ||
Comment 2•25 years ago
|
||
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.
Keywords: pp
OS: Mac System 9.0 → Windows NT
Comment 3•25 years ago
|
||
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.
Reporter | ||
Comment 4•25 years ago
|
||
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.
Keywords: smoketest
Putting on [nsbeta2+]. Does not need a fix ASAP for daily work per smoketest
nominee, but we should fix this for beta2.
Keywords: nsbeta2
Whiteboard: [nsbeta2+]
Reporter | ||
Comment 6•25 years ago
|
||
gah, this is no longer a problem --ie, using this afternoon's respun win32 comm
bits (on winNT).
Comment 7•25 years ago
|
||
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?
Comment 8•25 years ago
|
||
Sarah, please confirm that (1) this is still a problem, and (2) it is cross
platform. Thanks.
Reporter | ||
Comment 9•25 years ago
|
||
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.
Reporter | ||
Comment 10•25 years ago
|
||
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.
Reporter | ||
Comment 11•25 years ago
|
||
another note: this recent problem occurred on linux (different session, too)
Comment 13•25 years ago
|
||
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.
Reporter | ||
Comment 14•25 years ago
|
||
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).
Comment 15•25 years ago
|
||
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 16•25 years ago
|
||
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..."
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 17•25 years ago
|
||
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.
Status: REOPENED → ASSIGNED
Comment 18•25 years ago
|
||
Fix checked in. Changed file is wallet.cpp.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 19•25 years ago
|
||
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..."
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 20•25 years ago
|
||
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.
Status: REOPENED → ASSIGNED
Comment 21•25 years ago
|
||
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 22•25 years ago
|
||
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...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Reporter | ||
Comment 23•25 years ago
|
||
capturing/prefilling works using existing profiles on the 3 platforms.
Comment 24•25 years ago
|
||
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.
Updated•25 years ago
|
Status: REOPENED → ASSIGNED
Target Milestone: M16 → M17
Comment 25•24 years ago
|
||
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).
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Comment 26•24 years ago
|
||
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•24 years ago
|
Status: REOPENED → ASSIGNED
Comment 27•24 years ago
|
||
Fix checked in again. Give it a try sarah.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 28•24 years ago
|
||
vrfy [using existing profiles] w/commercial trunk bits 2000.06.14.08-m17 on
linux, Mac and winnt. whew!
Status: RESOLVED → VERIFIED
Updated•16 years ago
|
Assignee: morse → nobody
Product: Core → Toolkit
QA Contact: bugzilla → form.manager
Target Milestone: M17 → ---
Version: Trunk → unspecified
You need to log in
before you can comment on or make changes to this bug.
Description
•