Closed Bug 149126 Opened 21 years ago Closed 20 years ago

Mail Client doesn't work correctly with Open Office with rpm builds


(Core Graveyard :: X-remote, defect)

Not set


(Not tracked)



(Reporter: gsathis, Assigned: blizzard)




(2 files, 4 obsolete files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020523
BuildID:    2002052316

I have installed tarball installation under /opt/programs/mozilla. I edited
/opt/programs/mozilla/mozilla and exported MOZILLA_FIVE_HOME as
/opt/programs/mozilla. I configured OpenOffice to use external program
/opt/programs/mozilla/mozilla for sending emails directly from Openoffice
Writter or Calc. Everything worked fine. i.e when you do File ->Send->Document
as E-Mail, it will open the mozilla-mail client and attach the document as

The problem comes in if I have rpm builds that I have downloaded. I installed
all the necessary mozilla rpms. In the OpenOffice I changed the external program
as /usr/bin/mozilla. If try to send the document as email, I get the following
error when there are no mozilla instances running

/usr/lib/mozilla/mozilla-bin: relocation error: /usr/lib/ undefined
symbol: __vt_24nsGetServiceByContractID

If there is already an instance of mozilla browser or mozilla mail running, it
opens up compose window, but it doesn't attach the document.I strongly believe
it has something to do with rpm builds since it is working just fine under
tarball install.

Reproducible: Always
Steps to Reproduce:
1. Install the mozilla rpms
2. Configure Openoffice to use mozilla for mail
3. try to send a document as email
Well, for starters, the tarball builds and the rpm builds are built with
different compilers.  At a glance, it looks as though you're mixing different
mozilla installation libs.  Could you verify that MOZILLA_FIVE_HOME is unset
(the script should handle that itself)?  Also make sure that you don't have
multiple versions of the rpms installed.   What distribution are you running on?
 What version of libc do you have installed?  Does running /usr/bin/mozilla work
outside of OpenOffice?
Outside OpenOffice, yes /usr/bin/mozilla works fine. I am not able to note any
difference. In /usr/bin/mozilla, MOZILLA_FIVE_HOME is set to /usr/lib/mozilla
and is exported in the first few lines.

I have Redhat 7.3 installation. I am having the following packages as far as
libc go.


Infact, I have been following this bug since Redhat 7.2 and the RPMS since
mozilla 0.99 have this problem. I was thinking I am doing something wrong and
since it is consistent across various revision level, I thought I need to get
some help and may be a bug in rpm build or mozilla.

No, I don't have multiple versions of rpms installed. All the packages I have
installed are rc3. 
It sounds like you have some random library from an old installation lying
around somewhere.
I have made a fresh RedHat 7.3 installation. I have installed the following packages


and I have the following glibc packages


I have installed j2re-1.4.0_01-fcs rpm and OOo_1.0.0_LinuxIntel_install tarball

Same error occurs.

/usr/lib/mozilla/mozilla-bin: relocation error: /usr/lib/ undefined
symbol: __vt_24nsGetServiceByContractID

I am able to reproduce the error on a fresh clean install of RedHat 7.3 (no
redhat updates applied for any of the packages)
What does 'ldd /usr/lib/' return and what does 'ldd
/usr/lib/mozilla/mozilla-bin' return?
Priority: -- → P5
Target Milestone: --- → Future
There is no /usr/lib/ There is a /usr/lib/mozilla-1.0.0/
file. I did a 'ldd /usr/lib/mozilla-1.0.0/' The following is the result => not found => not found => not found => not found => /lib/i686/ (0x4002a000) => /lib/ (0x4003e000) => not found => /lib/i686/ (0x42000000) => /usr/lib/ (0x40042000) => /lib/i686/ (0x40085000)
        /lib/ => /lib/ (0x80000000)

Also there is no mozilla directory in /usr/lib instead there is a mozilla-1.0.0
directory there. The result of 'ldd /usr/lib/mozilla-1.0.0/mozilla-bin' => not found => not found => not found => not found => not found => not found => not found => /lib/i686/ (0x40026000) => /lib/ (0x4003a000) => /usr/lib/ (0x4003d000) => /usr/lib/ (0x4016b000) => /usr/lib/ (0x401a0000) => /usr/lib/ (0x401a3000) => /usr/X11R6/lib/ (0x401c8000) => /usr/X11R6/lib/ (0x401d0000) => /usr/X11R6/lib/ (0x401dd000) => /lib/i686/ (0x402b2000) => /lib/i686/ (0x42000000) => /usr/lib/ (0x402d4000)
        /lib/ => /lib/ (0x40000000)

Very  strange. Your error from comment #4 said /usr/lib/  Have you
tried  removing  /usr/lib/mozilla/component.reg  and running
'/usr/lib/mozilla/ /usr/lib/mozilla/regxpcom' ? Then try running
the browser.
I upgraded the browser to 1.0 version and removed
/usr/lib/mozilla-1.0.0/component.reg  and ran
'/usr/lib/mozilla-1.0.0/ /usr/lib/mozilla-1.0.0/regxpcom'

Now, when I do file->send->Document as Email, it opens up the mozilla mail
client compose window (no errors), but it did not attach the document.

With tar install, it does attach the document perfectly.
Use the /usr/lib/mozilla-1.0.0/ script.
I executed that perl script and it didn't help either.
Do you actually have a file called /usr/lib/

Till about mozilla-1.0rc3, the file was there in /usr/lib/ directory.
I filed this bug when I was in RC3. I have moved to 1.0 version now. This
morning, I made a fresh RH7.3 installation this morning to answer your question
correctly. I removed all the mozilla packages from RH7.3 default installation.
It still left out /usr/lib/mozilla with some files in it. I removed that
directory now I installed the following packages


I installed the other packages as described in comment #4.

Now, is in /usr/lib/mozilla-1.0.0/ directory. I checked rc2 rpms and
rc3 rpms that I have. That file was in /usr/lib directory and not in 1.0
release, I think you have moved it to /usr/lib/mozilla-1.0.0/ dir.

Coming to the problem, doing file->send->document as email, still doesn't work
correctly. i.e. it does not attach the document. There is one difference, I
don't get the relocation error of /usr/lib/ anymore.

Note: Till about my comment #4, I was on RC3 and on #6 I moved to 1.0.0. All my
reference in this comment are based on Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.0.0) Gecko/20020605.
The problem now sounds like a x-remote issue which I know the rpm scripts handle
differently than the tarball scripts. 
Over to Blizzard.
Assignee: seawood → blizzard
Priority: P5 → --
Target Milestone: Future → ---
Does openoffice have hooks into mozilla or something?  This is New Knowledge to
me if it does.
Open Office have hooks to Netscape 6 rather than mozilla directly. But, since
Netscape6 is technically mozilla, it works.(but with tar install of mozilla only)

To configure openoffice for this, you have to open the Writer program of
OpenOffice. From the menu on the top, select tools, goto options. Expand the section, and click on External Programs. You will find the form
to put in the information about which program to use, if there is http, https,
ftp,mailto links were found in the document. Also there is a place to put path
of netscape 6.x to send document as email.

I hope the above information will help you to reproduce the bug that I am
talking about.
I can reproduce this with the patched script from bug 122698. 
OpenOffice does send-document-as-email by creating a temporary file and then doing

mozilla -compose attachment=file:///blah/blah/blah.sxw

the mozilla script sees "-compose" and does

mozilla-xremote-client "xfeDoCommand(composeMessage)"

and so drops the attachment.  xremote does not currently understand attachments.
however, if there is already a running process, not using xremote will just
bring up the Select Profile dialog, which is also not what you want.

BTW: I couldn't get OpenOffice to not set MOZILLA_FIVE_HOME to
nsAppRunner passes the attachment=xxxxxxxxxxxxx as an "argument" to
nsWindowWatcher's OpenWindow (nsAppRunner considers atachment=xxx to be the
"value" for the "-compose" argument).  The compose window seems to take a
laundry list of arguments (to,subject,body...)

XRemoteService could do the same (also would need to open messengercompose.xul
itself), but I'm not sure how the XRemote commandline would look...

mozilla -remote "xfeDoCommand(composeMessage,attachment=xxxxxxxxxx)"

This could actually be done with all the xfeDoCommands (none currently pass any
arguments to OpenWindow).  Mail allows you to specify folder/messsage by URI. 
Browser doesn't seem to do anything useful.

WONTFIX?  seems a bit like featuritus (would be rarely used), but wouldn't be
hard to implement and would be pretty slick.

=> XRemote (this would be impossible to fix from the script alone)
Assignee: blizzard → seawood
Assignee: seawood → blizzard
Component: Build Config → X-remote
QA Contact: granrose → blizzard
the patch could probably be cleaned up somewhat, but works.  the following work
mozilla -remote "xfeDoCommand(composeMessage)"
mozilla -remote "xfeDoCommand(composeMessage,attachment=file:///tmp/something)"

mozilla -remote

this patch would also fix XRemote's involvement with bug 117114 by passing a
pointer to null argument instead of a null pointer (trick WindowWatcher into
thinking it's a dialog).
marking NEW
Ever confirmed: true
the patch also makes it possible to open any folder from any mail/news account:

mozilla -remote "xfeDoCommand(openInbox,mailbox://"

that doesn't seem particularly useful to me, but it's to be one of the lofty
objectives in bug 101169.
Keywords: mozilla1.2
Attachment #89505 - Attachment is patch: true
Keywords: patch
Blocks: 122698
*** Bug 204690 has been marked as a duplicate of this bug. ***
Attached patch update for the prior patch (obsolete) — Splinter Review
I want the feature to do integration with Mozilla mailer, so update the patch
to the recent code base.
The update mainly lies in:
1). nsISupportsString instead of nsISupportsWString
2). nsAutoString instead of nsString
3). whitespace instead of comma as the separator between arguments.
add cc
It would be really nice if the patch could be added when 1.4 released.
Anyone help to review?
Attachment #122731 - Flags: superreview?(dmose)
Attachment #122731 - Flags: review?(blizzard)
Blizzard and dmose,

Please take a look at this patch. If possible, we'd like to put it in 1.4
release. Thx a lot.

Comment on attachment 122731 [details] [diff] [review]
update for the prior patch

Index: mozilla/xpfe/components/xremote/src/XRemoteService.cpp
RCS file: /cvsroot/mozilla/xpfe/components/xremote/src/XRemoteService.cpp,v
retrieving revision 1.27
diff -u -r1.27 XRemoteService.cpp
--- mozilla/xpfe/components/xremote/src/XRemoteService.cpp	7 Mar 2003
00:24:27 -0000	     1.27
+++ mozilla/xpfe/components/xremote/src/XRemoteService.cpp	8 May 2003
05:19:56 -0000
@@ -499,6 +499,38 @@

+XRemoteService::FindRestInList(nsCString &aString, nsCString &retString,
+			       PRUint32 *aIndexRet)
+  // init our return
+  *aIndexRet = 0;
+  // make a copy to work with
+  nsCString tempString = aString;

a) Since you're going to give up if there's no comma character, why not
do that FindChar first and then use Substring() to copy it into
TempString?  This will save a copy in the case where you give up.

+  PRInt32   strIndex;
+  // find out of there's a , at the start of the string
+  strIndex = tempString.FindChar(' ');

b) It doesn't look to me like the above comment is correct.  The code
looks for a ',' anywhere in the string.

+XRemoteService::GetComposeLocation(char **_retval)
+  // get the Compose chrome URL
+  *_retval =
+  return NS_OK;

c) Make the argument be a const char **, and just set the pointer to
"string" directly.  This is a constant string which will point into a
.rodata section or equivalent, so there shouldn't be any ownership

+  // see if there are any arguments on the end
+  nsCString restArgument;
+  PRUint32 index = 0;

d) The first thing FindRestInList is set index to 0.  Why do it here also?

+  FindRestInList(aArgument, restArgument, &index);
+  if (!restArgument.IsEmpty())
+    aArgument.Truncate(index);  
+  nsCOMPtr<nsISupportsString> arg;
+  arg = do_CreateInstance(NS_SUPPORTS_STRING_CONTRACTID);

e) use the do_CreateInstance(..., &rv) form and check the return value, please.

+  nsAutoString argValue;
+  argValue.AssignWithConversion(restArgument.get());

f) AssignWithConversion is deprecated.	I suspect you want either
NS_ConvertASCIItoUCS2 or NS_ConvertUTF8toUCS2, if you know that the
input will be in one of those two encodings.  Or could it be in some
system specific encoding other than those?

   // open a new compose window
   else if (aArgument.EqualsIgnoreCase("composemessage")) {
-    nsCString tempString("mailto:");
-    rv = OpenURL(tempString, nsnull, PR_FALSE);
+    /* 
+     *  Here we change to OpenChromeWindow instead of OpenURL so as to
+     *  pass argument values to the compose window, especially attachments 
+     */  
+    nsXPIDLCString composeLocation;
+    GetComposeLocation(getter_Copies(composeLocation));
+    if (!composeLocation)
+      return NS_ERROR_FAILURE;

g) Assuming you've changed GetComposeLocation as I suggested, you no
longer want an nsXPIDLCString here, because's there no need to free
anything.  Better to check the return value here, not look at
composeLocation itself.
Attachment #122731 - Flags: superreview?(dmose) → superreview-
Update the patch according to the points dmose mentioned.
Attachment #122731 - Attachment is obsolete: true
Attachment #123125 - Flags: superreview?(dmose)
Attachment #123125 - Flags: review?(blizzard)
Comment on attachment 123125 [details] [diff] [review]
XfeDoCommand accept secondary Argument_2

>+  if (NS_FAILED(rv)) return rv;

Put the if and then clauses on separate lines, please.	The way it stands, it's
not possible to set a break on the return in a debugger.

Make that change, and you've got
Attachment #123125 - Flags: superreview?(dmose) → superreview+
put the if and then clauses on separate lines
Attachment #123125 - Attachment is obsolete: true
Attachment #123228 - Flags: review?(blizzard)
Comment on attachment 123228 [details] [diff] [review]
xfeDoCommand accept secondary arugments patch 3

this feature is cool and if possible, should be added to moz 1.4
Attachment #123228 - Flags: approval1.4?
Attachment #123228 - Flags: review?(blizzard) → review?(antonio.xu)
Attachment #123228 - Flags: review?(antonio.xu) → review+
please remove extra whitespace at the end of the line in your patch, and I still
think you should use nsCAutoString instead of nsCString, but anyway,just remove
extra whitespace is ok.
Make that change, and you've  
revome the extra whitespaces and tabs.
Attachment #123228 - Attachment is obsolete: true
Attachment #123487 - Flags: approval1.4?
Comment on attachment 123487 [details] [diff] [review]
xfeDoCommand accepts the secondary argument patch 4

This needs blizzard's review still.
Attachment #123487 - Flags: approval1.4? → review?(blizzard)
Attachment #123228 - Flags: approval1.4?
With this patch this works:

./mozilla -remote 'xfedocommand(composemessage,attachment=file:///tmp/test.txt)'

but this doesn't:

./mozilla -remote 'xfedocommand(composemessage,,attachment=file:///tmp/test.txt)'

Note the comma after composemessage.  In the past all of our arguments take a
form like this:

openurl(, new-tab)

and they work.  This would change that.
Attachment #123487 - Flags: review?(blizzard) → review-
Attachment #122731 - Flags: review?(blizzard)
Attachment #123125 - Flags: review?(blizzard)
Thanks blizzard!
I took whitespace as the separator just because the secondary argument uses
comma as separator, too. 
Since it will cause inconsistency of the xfeDoCommand format, I've modified to
comma instead of whitespace as the separator.
Please review again.
Attachment #123487 - Attachment is obsolete: true
Attachment #123739 - Flags: review?(blizzard)
Comment on attachment 123739 [details] [diff] [review]
xfeDoCommand accepts secondary argument.


Seems to work pretty well and the code looks fine.  Thanks!
Attachment #123739 - Flags: review?(blizzard) → review+
Attachment #123739 - Flags: approval1.4?
Comment on attachment 123739 [details] [diff] [review]
xfeDoCommand accepts secondary argument.

a=asa (on behalf of drivers) for checkin to 1.4
Attachment #123739 - Flags: approval1.4? → approval1.4+
checked into trunk
Closed: 20 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.