Mozilla asserts if compiled --disable-client-wallet

VERIFIED FIXED

Status

()

P3
normal
VERIFIED FIXED
20 years ago
10 years ago

People

(Reporter: cls, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

20 years ago
First, you need to apply this patch to get it to compile:
RCS file: /cvsroot/mozilla/xpfe/browser/src/nsBrowserInstance.cpp,v
retrieving revision 1.19
diff -u -r1.19 nsBrowserInstance.cpp
--- nsBrowserInstance.cpp       1999/09/23 17:46:03     1.19
+++ nsBrowserInstance.cpp       1999/09/26 06:25:31
@@ -78,9 +78,9 @@
 #include "nsIDocumentLoader.h"
 #include "nsIObserverService.h"
 #include "nsFileLocations.h"
+#include "nsIFileLocator.h"

 #ifdef ClientWallet
-#include "nsIFileLocator.h"
 #include "nsIFileSpec.h"
 #include "nsIWalletService.h"
 static NS_DEFINE_IID(kIWalletServiceIID, NS_IWALLETSERVICE_IID);

Here's the script output:
cls@amadeus:bin> ./mozilla-apprunner.sh
MOZILLA_FIVE_HOME=/opt/cls/obj/dist/bin
  LD_LIBRARY_PATH=/opt/cls/obj/dist/bin
      MOZ_PROGRAM=./apprunner
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
nsNativeComponentLoader: autoregistering /opt/cls/obj/dist/bin/components
nsNativeComponentLoader: autoregistering succeeded
nsUnixToolkitService: Using 'gtk' for the Toolkit.
NS_SetupRegistry() MOZ_TOOLKIT=gtk, WIDGET_DLL=libwidget_gtk.so,
GFX_DLL=libgfx_gtk.so
started appcores
GFX: dpi=100 t2p=0.0694444 p2t=14.4 depth=16
Using '/opt/cls/obj/dist/bin' as the resource: base
initialized appshell
Profile Manager : Profile Wizard and Manager activites : Begin
Profile Manager : Command Line Options : Begin
Profile Manager : Command Line Options : End
ProfileName : cls
ProfileDir  : /home/cls/.mozilla/cls
Profile Manager : Profile Wizard and Manager activites : End
PreCondition: "dup release" (0 != mRefCnt) at file
/opt/cls/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 155
Break: at file /opt/cls/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line
155
cls@amadeus:bin>

Updated

20 years ago
Status: NEW → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → INVALID

Comment 1

20 years ago
You must have an old tree.  That fix was made on September 18.  It is revision
1.17 of nsBrowserInstance.cpp.
(Reporter)

Updated

20 years ago
Status: RESOLVED → REOPENED
(Reporter)

Comment 2

20 years ago
I updated my tree on the evening of Sep 25 and the version of
nsBrowserInstance.cpp is 1.19 (as the patch shows).  Which problem were you
referring to as fixed....the compile time problem or the runtime problem?

Comment 3

20 years ago
*** Bug 14938 has been marked as a duplicate of this bug. ***

Updated

20 years ago
Status: REOPENED → ASSIGNED

Updated

20 years ago
Resolution: INVALID → ---
Target Milestone: M14

Comment 4

20 years ago
I was referring to the compile-time problem.  But I see what the problem is.
Previously I moved nsFileLocations.h outside of the ifdef.  Now you are saying
that I also need to move nsIFileLocators.h outside.  I misread it and thought
you were referring to the file I previously moved.  Sorry.

As far as the runtime problem, I don't understand what your output is saying.
Can you describe the problem in words?  Thanks.
(Reporter)

Comment 5

20 years ago
Mozilla asserts at line 155 of nsAppShellService.cpp which I've pasted below:
     NS_IMPL_ISUPPORTS(nsAppShellService, kIAppShellServiceIID);

From there, I'm a bit lost as it descends into macro hell and I'm not familiar
with the entire xpcom setup.  Based upon the "dup release" message, I'm guessing
that something is unconditionally trying to free a reference to the
k*WalletService?ID .  A cursory grep of the tree shows that
xpfe/bootstrap/nsAppRunner.cpp has several references to k*WalletService?ID that
are not ifdef'd but I have no idea if they are part of the problem.

Updated

19 years ago
Target Milestone: M14 → M11

Comment 6

19 years ago
On giving some more thought to this, I'm going punt on this.  Here's why.

The ifdefs and conditional compilation that were put in for ClientWallet were
done so just for the landing.  In case the landing failed, I would be able to
quickly disable it rather than having to back out the changes from every file
that I touched.  Now that it is landed, the ifdef should never be turned off.

As far as modularity goes, ClientWallet is not a problem.  If you don't want to
use it, simply remove its dll from the components directory.  That should work
-- if it doesn't then that's a serious bug and I will fix it.

As far as precedence goes, consider necko.  I'll wager you that we will fail
miserably if we ever tried to build today with necko turned off.

So what I will do is remove the few remaining vestiges of ifdef ClientWallet (in
nsBrowserWindow.cpp and nsBrowserInstance.cpp).  Then I'll mark this bug as
fixed.

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago19 years ago
Resolution: --- → FIXED

Comment 7

19 years ago
I removed the ifdefs from nsBrowserInstance since that is the one that affect
the mozilla build.  Marking bug as fixed.
(Reporter)

Comment 8

19 years ago
Ok, that still doesn't resolve the problem of the "broken" configure option but
I'll just remove the option.  The situation is hardly comparable to the necko
case as necko was completely replacing another essential piece of Mozilla
whereas the wallet is just an added extension.  Speaking of which, since the
wallet is an extension, shouldn't the building of it be controlled by the
--enable-extensions flag?

Comment 9

19 years ago
I have no idea what the enable-extensions flag is or how it is used.
(Reporter)

Comment 10

19 years ago
--enable-extensions is a configure option that allows builders to turn on (or
off) certain extensions to mozilla, like rginda's irc extension.  Unfortunately,
this is not going to work for client-wallet.  If the extensions/wallet directory
doesn't exist in the tree (or to be more accurate, nsIWalletService.h isn't
exported to $DIST), then the tree will not build.  If client wallet is truly an
extension, then Mozilla should be able to build with that tree missing/not being
traversed.  If it's not an extension, then it shouldn't be in the extensions
directory.

Updated

19 years ago
Status: RESOLVED → VERIFIED
Assignee: morse → nobody
Component: Form Manager → Form Manager
Product: Core → Toolkit
QA Contact: paulmac → form.manager
Target Milestone: M11 → ---
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.