27023 - Tasks|My Wallet|Change Password doesn't work in mail

Status: VERIFIED FIXED

(SeaMonkey :: Passwords & Permissions, defect, P3)

Description

[Ninoschka Baca]

Build 2000-02-07-08M14: NT4, Linux 6.0, Mac 8.5.1

Overview: In any component (Browser, Composer, Mail) select Tasks|My 
Wallet|Change Password and nothing happens. Should this be working for Beta1?

Comment 1

[sairuh (rarely reading bugmail)]

ss belongs to morse.

Comment 2

[Stephen P. Morse]

This is working fine for me with a tree that I pulled this morning (and updated 
to fix all the dialog bustage that occured this morning).  Could be you were 
getting hit by some of that dialog bustage.  So I'm closing this out.  If you 
still see this problem with tomorrow's build, reopen and we'll try to figure out 
what you are doing differently for me.

Comment 3

[Ninoschka Baca]

Build 2000-02-09-08M14: NT4

It doesn't work for me with this build. I've tried:
- POP or IMAP
- After getting messages and prompted to enter a password I've tried not saving 
the password. Also tried saving the password but it doesn't make a difference.

Comment 4

[Stephen P. Morse]

I'm a little confused by your last comment about using POP or IMAP.  The 
change-password dialog has nothing to do with your remembering of passwords for 
specific sites or functions.  Instead it involves changing the master password 
that unlocks the password database.

I just tried it again, using a tree that I pulled a few hours ago.  If I had 
already unlocked the database in the current session, then I indeed get the 
change-password dialog when I select it from the menu (except that it's 
partially obscured by the menu for which I just filed bug 27204).  So that part 
is working fine.

However, if I hadn't already unlocked the database, then nothing happens.  This 
is normal behavior.  If you feel that something should happen (e.g., a dialog 
saying that there isn't any master password to change), then report that in a 
separate bug.

So you probably didn't have the master password established yet and that is why 
you aren't getting the change-password dialog.  But as described above, this is 
normal behavior.  Therefore closing this out as invalid.

Comment 5

[sairuh (rarely reading bugmail)]

i just spoke with nbaca, and i was able to reproduce the problem. this is what
we did (linux comm bits, 2000-02-09-08):

0. we started with a new profile.
1. went to Tasks > Mail, which prompted to create a mail account.
2. got the 3-pane mail window, clicked on Get Msg button. prompted for mail
server password, which we entered. this Password dialog just had 1 field for the
passwd and a checkbox to save it, which we didn't select.
3. within the mail window, went to Tasks > My Wallet > Change Password.
result: nothing happens, ie, *no* dialog appears at all. shouldn't we get some
sort of dialog asking to setup a master passwd? (since it's a new profile)? or
what? (side note: yes, we agree that POP and IMAP have nothing to do with this,
really.)
4. but wait, there's more: we go to a browser window and attempt Tasks > My
Wallet > Change Password.
result: the same as in step 3.

note A: i went thru the above recipe with my own existing profile... i got the
same results at step 3 (no dialog while in mail). but at step 4, i did get the
master passwd while in the browser (then again, i do have a master passwd setup
for my profile).

note B: we restarted another session with the new profile, tried to change
passwd within the browser, and still got no dialog.
so now we ask ourselves: is it that we need to actually *save* the mail passwd
in order to be prompted for the master passwd dialog? we test this, and sure
enough, we get the dialog asking to enter a master passwd. *however* while we're
still in the mail window, when we try to change the master passwd (Tasks > My
Wallet > Change Password, as usual), we *still* don't get the master passwd
dialog! the odd thing here is that when we go to the browser window, this isn't
a problem: we *do* get the master passwd dialog there.

anyhow, pardon the long-winded story here. i've updated the summary.

Comment 6

[Stephen P. Morse]

Long-winded summaries are good -- they help me see where the confusion lies.

I can explain nearly everything you described.  Keep in mind that the 
change-password refers to the master password only, not the mail password.  So 
when you set up a mail password and don't save it, you don't have a database 
(assuming you haven't saved a password previously) and hence don't have a master 
password.  So doing a change-password at that time is supposed to do nothing as 
I described above.  If that is confusing people, then open a new bug saying that 
we should put up a warning dialog if user tries to change master password and 
doesn't have any (please don't morph this bug report to include that).

That explains everything in your steps 1 through 4.  There is no bug there.  But 
there are some things in your notes that aren't kosher yet.

Note A:  If you had a master password already set up, then you should have been 
able to use change-password both in the browser as well as in mail.  The fact 
that it wasn't coming up when in mail was wrong.  I wonder if someone changed 
the meaning of the menu buttons when in mail.  I'll investigate.

Note b: The first part of this note is explainable.  Yes, you need to save a 
password first (which forces you to create a master password) before you can use 
the change-master-password function.  Again, this is as I explained above.  But 
the next part of your note agains deals with the problem that once you had 
created a master password, you could change it in browser but not in mail.  
That's the same problem that I commented on in your Note A and is what I will be 
investigating.

Pardon my long-winded reply but I hope it clarifies a few points.

Comment 7

[Stephen P. Morse]

It's as I suspected.  The a good part of the wallet submenu does not work from 
mail.  Clicking on the item raises javascript exceptions.  Specifically, I get 
the following javascript error on the console:

   appcore is not defined
   file: chrome://global/content/tasksOverlay.js
   line number 279

Here's a list of what's in the wallet submenu and an indication of whether or 
not it they raise the javascript error from mail.  Of course I wouldn't expect 
some of them to work in mail since they have no meaning -- e.g., form-fill, 
form-capture, etc.

safe-form-fill -- raises exception
quick-form-fill -- raises exception
capture-form -- raises exception
wallet-content -- ok
display-signons -- ok
display-cookies -- ok
samples - raises exception
change-password -- raises exception
  

Comment 8

[Stephen P. Morse]

Some more info.  Safe-form-fill, quick-form-fill and capture are probably 
expected to raise the javascript error because they have no meaning when looking 
at mail.  The javascript error for samples is a different one (window.content 
has no properties) and is also probably expected in the context of mail.

So that leaves just change-password as one that should work in the context of 
mail but doesn't.

Comment 9

[Suresh Duddi (gone)]

Steve are you the right person to fix this. If not, send it over to me.

Comment 10

[Stephen P. Morse]

I was hoping someone would take this one off my hands.

Comment 11

[Suresh Duddi (gone)]

Phil/Peter would this be in your group. Looks like a menu item works from
browser but not from mail.

Since this starts with mail, I am reassinging to phil.

Comment 12

[Suresh Duddi (gone)]

Ccing trudelle: Something to do with appcores not being defined when a menu item
is invoked from mail. Works great when invoked from browser.

Comment 13

[Phil Peterson]

Maybe an overlay issue? Paul, can you take a look?

Comment 14

[hangas]

Well the problem here is a simple one, but the solution may not be painless.  The 
problem is the the function WalletAction() has been moved to tasksOverlay.js, it 
uses a variable 'appcore' to access functions like walletChangePassword().  
Unfortunately, appcore is only defined in the browser window.  This would be no 
problem, but appcore is defined as an instance of the browser component.  Since 
tasksOverlay needs to work in any window it should not require that the browser 
component be available.  So we should either decide that we will always install 
the browser component, or we should move these functions to a global location 
that will always be installed.

Sending to morse for decision.  If we decide that the browser will be installed 
in every situation that mozilla is used, then we can access the browser component 
from the taskOverlay.js file.  I will be happy to take the bug back if this is 
the case.

Comment 15

[Stephen P. Morse]

Well we've now gone around in a circle.  From trudelle to morse to dp to phil to 
hangas and back to morse.  I'm probably not the right person for this one but 
I'll take a look at it.

To answer hangas' question, the browser should not be installed in every 
situation that mozilla is used.  I'm sure the mail team will take that position.

Comment 16

[Suresh Duddi (gone)]

I dont know this area too well either. One thing that came to my mind is can we 
getservice() walletservice and call the walletChangePassword() from there 
instead of using an appcores. xpconnect works like a charm. I see 
WALLET_ChangePassword() exported from nsIWalletService.idl

The other option for beta is can we disable this menu item in mail. Paul can 
you answer this.

Paul ? steve ?

Comment 17

[Stephen P. Morse]

dp,

You wouldn't want to disable this for mail.  The mail team just switched over to 
using single-signon.  So it would look strange for a mail user to be able to 
create a master password and save his mail password all from within mail, but 
then he has to leave mail and go to the browser if he wants to change the master 
password.

I'm sure there is a way to access c-code from javascript while in mail so that 
is why I never passed this off originally until you asked me to do so (back on 
2-11).  Probably something of the nature that you just described above.  I'll 
continue to investigate.

Comment 18

[Stephen P. Morse]

Fix checked in.  Did exactly what dp described.  Change is in tasksOverlay.js.

Besides doing this, I also added an alert that pops up when you select 
change-password and have never previously established a password.  I figured 
that's better than doing nothing and might have added to some of the confusion 
when this bug report was originally filed.

Comment 19

[sairuh (rarely reading bugmail)]

verified using

linux: comm bits 2000021609
winNT: non-comm bits 2000021608
macOS: comm bits 2000021608