28442 - win: unable to change master passwd

Status: VERIFIED FIXED

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

Description

[sairuh (rarely reading bugmail)]

methinks this is unrelated to bug 28148, since the browser doesn't hang here. i
just cannot change the master password (though i can set it initially).

0. create a new profile, and launch seamonkey.
1. go to http://slip/projects/marvin/wallet/login.html.
2. enter squiddy/calamari, hit Login button.
3. when the Confirm dialog appears, click Yes to save the username/passwd.
4. when the Password dialog appears, enter a non-null master passwd, click OK.
5. during the same session, try to change the master passwd, ie, go to Tasks >
Autofill > Change Password.
result: nothing happens, ie, no dialog appears at all.
6. quit and restart seamonkey with the same profile.
7. attempt to change the master password (go to Tasks > Autofill > Change
Password).
result: still nothing. no dialogs.

Comment 1

[leger]

Putting on the PDT+ radar for beta 1.

Comment 2

[Stephen P. Morse]

Are you running with the netscape build or the mozilla one?  I just tried this 
with a fresh tree on the mozilla build and was unable to reproduce.

Comment 3

[Stephen P. Morse]

And I just pulled and built a commercial winnt tree.  Again am unable to 
reproduce.

Comment 4

[Stephen P. Morse]

Sarah, are you still seeing this.  I'm not and I can't fix it if I can't 
reproduce it.

Comment 5

[sairuh (rarely reading bugmail)]

still a problem for me. tested with today's opt comm bits on winNT [2000022108].

Comment 6

[sairuh (rarely reading bugmail)]

here's the console output i get from the opt winNT bits from 2000022108:

JavaScript Error: uncaught exception: [Exception... "Could not convert 
JavaScript argument (NULL value can not be used for a C++ reference type) arg 0 
[nsISupports.QueryInterface]"  nsresult: "0x8057000b 
(NS_ERROR_XPC_BAD_CONVERT_JS_NULL_REF)"  location: "JS frame :: 
chrome://global/content/tasksOverlay.js :: WalletAction :: line 261"  data: no]

Comment 7

[Stephen P. Morse]

OK, I just downloaded the commercial optimized bits, and finally I am able to 
see the failure.  So it doesn't fail in the commercial debug build, only the 
optimized one.  Hmmm.

Here some more context for the javascript error that Sarah is reporting:

  if (action == "password") {
    /* process "password" independent of appcore so it can be called from mail 
*/
    wallet = Components.classes['component://netscape/wallet'];
    wallet = wallet.getService();
==> wallet = wallet.QueryInterface(Components.interfaces.nsIWalletService);
    wallet.WALLET_ChangePassword();
    return;
  }

Comment 8

[Stephen P. Morse]

John,

dp said you were the expert on problems relating the the xpidl compiler.  Do you 
have any ideas as to what this problem could be.  The javascript error above 
probably says it all.

Comment 9

[John Bandhauer]

Looking in the packager manifests I see that wallet.xpt is not listed for all 
platforms. That is your problem.

Comment 10

[Stephen P. Morse]

Looking at the packager manifests (mozilla/xpinstall/packager/packages-*) I see 
what look like several anomalies.  I don't know enough about the packager to 
know whether or not they are errors.

Specifically, here are the entries for "wallet" that I find in those files:

packages-mac:viewer:Components:Wallet.shlb 
packages-mac:viewer:Components:wallet.xpt 
packages-mac:viewer:Components:WalletViewers.shlb 
packages-mac:viewer:chrome:wallet:*

packages-unix:bin/components/libwallet.so
packages-unix:bin/components/libwalletviewers.so
packages-unix:bin/components/walleteditor.xpt
packages-unix:bin/components/walletpreview.xpt
packages-unix:bin/chrome/wallet/*

packages-win:bin\components\wallet.dll
packages-win:bin\components\walleteditor.xpt
packages-win:bin\components\walletpreview.xpt
packages-win:bin\chrome\wallet\*

I came up with the following chart to try to make some sense out of the above:

                             win   unx   mac
                             ---   ---   ---
wallet.xpt                                x
walleteditor.xpt              x     x
walletpreview.xpt             x     x

(lib)wallet.dll/so/shlb       x     x     x
(lib)walletviewers.so/shlb          x     x

chrome/wallet/*               x     x     x

So that raises the following questions in my mind:

1. Do we need wallet.xpt in the win and unix files?
2. Do we need walleteditor.xpt and walletpreview.xpt in the mac files?
3. Do we need a walletviewers.dll in the win file?
4. Why is there no cookieviewer.xpt and signonviewer.xpt?

Should the component of this bug be changed to "installer" and reassigned to 
someone in that group?

Comment 11

[Stephen P. Morse]

See also bug 28436.  I wonder if the above analysis also explains that bug.  In 
that case, as in this one, the bug does not manifest itself when I build the 
product but q/a sees it in the bits that they install.

Comment 12

[John Bandhauer]

My understanding of installer stuff is that the owners of the individual modules 
are supposed to own the problem of making sure that their parts get represented 
in the correct manifests. I'm sure you can get help, but I don't believe that 
the xpinstall folks should be expected to know the nuances of every module - 
which parts are needed and which aren't. While we each can be expected to learn 
enough about xpinstall so that we can manage our modules.

As your chart shows this needs to be put this in order for this module.

Your makefiles control which interfaces from which .idl files end up in which 
.xpt files. You should have a handle on that. This information can be confirmed 
using xpt_dump.

The specific interface in question here was nsIWalletService. As you can see 
below it is clearly in wallet.xpt (on Windows at least)

[x:\seamonkey\mozilla\dist\win32_d.obj\bin\components]..\xpt_dump wallet.xpt | g
rep nsIWalletService
   - ::nsIWalletService (738cfd51-abcf-11d2-ab4b-0080c787ad96):

[x:\seamonkey\mozilla\dist\win32_d.obj\bin\components]..\xpt_dump walleteditor.x
pt | grep nsIWalletService

[x:\seamonkey\mozilla\dist\win32_d.obj\bin\components]..\xpt_dump walletpreview.
xpt | grep nsIWalletService

Comment 13

[Stephen P. Morse]

John, thanks for all your explanations.  First, let me correct my chart above (I 
was searching for wallet and hence missed some entries (such as wllt etc).

                             win   unx   mac
                             ---   ---   ---
wallet.xpt                                x
walleteditor.xpt              x     x
walletpreview.xpt             x     x
cookieviewer.xpt              x     x
signonviewer.xpt              x     x

(lib)wallet.dll/so/shlb       x     x     x

wlltvwrs.dll           \
liblibwalletviewers.so  |     x     x     x
WalletViewers.shlb     /

chrome/wallet/*               x     x     x

Next, here are the idl files that are in my modules and the corresponding xpt 
file that they wind up in:

nsIWalletEditor.idl  --> walleteditor.xpt
nsIWalletPreview.idl --> walletpreview.xpt
nsICookieViewer.idl  --> cookieviewer.xpt
nsISignonViewer.idl  --> signonviewer.xpt

nsIWalletService.idl  --> wallet.xpt
nsIKeyedStreamGenerator.idl --> wallet.xpt
nsIPasswordSink.idl --> wallet.xpt

So it appears that the answers to my questionss are as follows:

1. We need to add wallet.xpt to packages-unix and packages-win
2. We need to add walleteditor.xpt and walletpreview.xpt to packages-mac
3. We already have wlltvwrs.dll in packages-win
4. We need to add cookieviewer.xpt and signonviewer.xpt to packages-mac as well.    

John, can you please code review the changes described in 1, 2, and 4?  Thanks.

Comment 14

[Stephen P. Morse]

Updated packages-* files checked in.  That should fix this problem.

Comment 15

[sairuh (rarely reading bugmail)]

verified as fixed on winNT, using opt comm bits 2000022408.

Comment 16

[J.J. Enser]

Well, adding the 4 files below to packages-mac didn't help. The packaging script 

actually fails because they don't exist in that location (or anywhere else as a 

matter fact).

	walleteditor.xpt

	walletpreview.xpt

	cookieviewer.xpt

	signonviewer.xpt



I understand that this addition was based on what's in Win/Unix and was missing 

on Mac, but the parity is not always that simple, especially under "Components" 

where libraries and idl/xpt files may have a different name.

File existence and location should always be verified before updating the 

'packages-*' files.