Closed Bug 14932 Opened 25 years ago Closed 25 years ago

Mozilla asserts if compiled --disable-client-wallet

Categories

(Toolkit :: Form Manager, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: cls, Unassigned)

References

Details

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>
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
You must have an old tree.  That fix was made on September 18.  It is revision
1.17 of nsBrowserInstance.cpp.
Status: RESOLVED → REOPENED
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?
*** Bug 14938 has been marked as a duplicate of this bug. ***
Status: REOPENED → ASSIGNED
Resolution: INVALID → ---
Target Milestone: M14
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.
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.
Target Milestone: M14 → M11
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
I removed the ifdefs from nsBrowserInstance since that is the one that affect
the mozilla build.  Marking bug as fixed.
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?
I have no idea what the enable-extensions flag is or how it is used.
--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.
Status: RESOLVED → VERIFIED
Assignee: morse → nobody
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.