11093 - Can access wallet Form info even if cancel out of password dialogues

Status: VERIFIED FIXED

(Toolkit :: Form Manager, defect, P3)

Description

[kevinyen]

Known situations the above applies to:
1. Viewing wallet contents
2. Saving new Form info into Wallet

thx,
kevin

Comment 1

[Stephen P. Morse]

Absolutely.  That's a feature.  If you press cancel, or you enter a null
password and press OK, then no password is needed for future accesses to the
wallet data.

Comment 2

[kevinyen]

But the problem/situation occurs even if a password has been previously set.

In other words, here's a scenario:
1. I created a password in a previous session, the password is in effect
2. In the current session, I try viewing Wallet contents
3. The dialog comes up asking for the password
4. I hit "cancel"
5. I gain access.

If this is how it's supposed to be, I'm confused -- what good is the password?

Comment 3

[Stephen P. Morse]

I don't see that behavior at all.  I'm using a build from a tree that I pulled
Sunday morning.  So I'm closing this out as works-for-me.

Comment 4

[kevinyen]

I'm using today's build (aren't we all supposed to?).  080208.

Reopened bug.  Today's build has it.

Comment 5

[Paul MacQuiddy]

This works for me also with today's build. The wallet viewer opens for me if I
cancel out of the password dialogues, but there is no data.

Maybe you have some corrupted files? I would suggest deleting
c:\windows\mozregistry.dat and c:\program files\seamonkey\users50 and trying
again. Or actually moving them to a backup name.

Comment 6

[Stephen P. Morse]

Kevin,

Please don't keep reopening this bug after I keep closing it.  If I claimed that
it works-for-me, then Q/A will try it and determine if I am being honest or not.

Once again (for the third time today) I am closing out this report.

Comment 7

[Paul MacQuiddy]

Let's not get too caught up with who's resolving what which way. Let's figure
out why Kevin is seeing what he's seeing, since we can't reproduce it. Kevin, if
you still see this after cleaning up your files, please call me at 5321 and I'll
come over. Thanks.

Comment 8

[kevinyen]

build 080212

Started with totally clean install (deleted mozreg and user50 folder).  Then...

Here are all the steps, even those not directly related to a bug.
1. Went to amazon sample
2. Fill out some info
3. Said ok to saving the info I typed
4. created password at the password dialogue
5. Shut down browser, then re-started
6. Went to view wallet contents
7. "cancelled" out of the password dialogues
8. empty wallet content form appeared (this should be improved -- we should not
show this; maybe show a dialogue that says "sorry, wrong pwd; can't show".
I'll file this separately)
9. Went again to view wallet contents (this is a bug -- should give me opp to
enter pwd;; I'll file this bug separately)
10. Empty wallet content form appeared again
11. Close wallet content window
12. went to ebay sample and filled out info
13. said OK when asked if I wanted to save
14. Viewing Wallet contents reveals my ebay info;  again, no pwd required.

Paul Mac here: So I see what is going on, the info is being saved for the
current session, but it is not writing to hard drive. If you re-start the
browser, the info that had shown up in Wallet Contents (ebay stuff) is gone.
It also appears that this sequent of events will wipe out previous 'valid' info
that had been saved on previous sessions - I will check this out.

I will reopen yet again :-)

Comment 9

[Paul MacQuiddy]

I think the real bug here is that you are not asked for you password when you go
back into wallet contents a second time.

Comment 10

[Stephen P. Morse]

OK, let me address this one step at a time.  First of all, this is still
works-for-me because I do not go directly from step 7 to 8 but rather go through
the following two intermediate steps.  And I believe that Paul saw this as well
in his testing.

step 7.1.  I get a pop-up box saying "incorrect key, do you want to try again.
I press "cancel"

step 7.2.  I get a pop-up box saying "key failure, wallet will not be opened"

step 8:  At this point I probably should not give you the wallet viewer since
you were unable to provide the correct password.  I'll correct that.

step 9:  Again, I should refuse to give you the wallet viewer since you didn't
know the password (I'll modify that).  I will not give you another chance at
entering the password.  If you want to try again, you need to exit and reenter
the browser.  That is by design.

step 13: Now here's the first bug that I've seen.  You should not get the
message asking if you want to save since you previously refused to enter a
password.  You can open that as a separate report if you like -- I'll definitely
fix that.

Comment 11

[leger]

Clearing WorksForMe resolution due to reopen.

Comment 12

[kevinyen]

Steve,

Re: your Step 9, basically, we should treat "cancels" different from "wrong
entries"
More details:
1. If a user "canceled", then we should give the user another chance later in
teh same session to re-enter his password.  This would be good UE because a user
 might "cancel" for very legitimate reasons (e.g., knows will use browser for
two minutes then leave for an hour mtg).

2. If wrong passwords were entered in the password dialogue series, then it
sounds like a good idea to block access.  But do you think we should show a
dialogue/screen in this case explaining the situation?  I'm afraid of the user
clicking on QuickFill or view Wallet contents, with nothing happening
afterwards.  User will be perplexed, especially if he wasn't the one who
mis-typed the password.
How does the following dialogue look for this "lockout" situation?

"Please restart Navigator to use QuickFill.  The incorrect key was entered too
many times in this session".

I'm open to other ways to address "cancel" vs "wrong entry", but do feel it's
good for the feature to handle this.

thx,
kevin

Comment 13

[Paul MacQuiddy]

kevin, can you verify that the behavior is correct now?