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

Status: RESOLVED FIXED

(Core Graveyard :: X-remote, defect)

Description

[Sathiskumar Govindasamy]

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
attachment. 

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/libjsj.so: 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

Comment 1

[hacker formerly known as [e-mail]]

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?

Comment 2

[Sathiskumar Govindasamy]

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.

glibc-kernheaders-2.4-7.14
glibc-utils-2.2.5-34
glibc-common-2.2.5-34
glibc-2.2.5-34
glibc-devel-2.2.5-34

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. 

Comment 3

[Christopher Blizzard (:blizzard)]

It sounds like you have some random library from an old installation lying
around somewhere.

Comment 4

[Sathiskumar Govindasamy]

I have made a fresh RedHat 7.3 installation. I have installed the following packages

mozilla-1.0rc3-0
mozilla-mail-1.0rc3-0
mozilla-chat-1.0rc3-0
mozilla-nss-1.0rc3-0
mozilla-nspr-1.0rc3-0
mozilla-js-debugger-1.0rc3-0
mozilla-dom-inspector-1.0rc3-0
mozilla-psm-1.0rc3-0

and I have the following glibc packages

glibc-common-2.2.5-34
glibc-2.2.5-34

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

Same error occurs.

/usr/lib/mozilla/mozilla-bin: relocation error: /usr/lib/libjsj.so: 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)

Comment 5

[hacker formerly known as [e-mail]]

What does 'ldd /usr/lib/libjsj.so' return and what does 'ldd
/usr/lib/mozilla/mozilla-bin' return?

Comment 6

[Sathiskumar Govindasamy]

There is no /usr/lib/libjsj.so. There is a /usr/lib/mozilla-1.0.0/libjsj.so
file. I did a 'ldd /usr/lib/mozilla-1.0.0/libjsj.so' The following is the result

        libxpcom.so => not found
        libplds4.so => not found
        libplc4.so => not found
        libnspr4.so => not found
        libpthread.so.0 => /lib/i686/libpthread.so.0 (0x4002a000)
        libdl.so.2 => /lib/libdl.so.2 (0x4003e000)
        libmozjs.so => not found
        libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
        libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x40042000)
        libm.so.6 => /lib/i686/libm.so.6 (0x40085000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (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'

        libgkgfx.so => not found
        libjsj.so => not found
        libmozjs.so => not found
        libxpcom.so => not found
        libplds4.so => not found
        libplc4.so => not found
        libnspr4.so => not found
        libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40026000)
        libdl.so.2 => /lib/libdl.so.2 (0x4003a000)
        libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x4003d000)
        libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x4016b000)
        libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x401a0000)
        libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x401a3000)
        libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x401c8000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x401d0000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x401dd000)
        libm.so.6 => /lib/i686/libm.so.6 (0x402b2000)
        libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
        libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x402d4000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Comment 7

[hacker formerly known as [e-mail]]

Very  strange. Your error from comment #4 said /usr/lib/libjsj.so.  Have you
tried  removing  /usr/lib/mozilla/component.reg  and running
'/usr/lib/mozilla/run-mozilla.sh /usr/lib/mozilla/regxpcom' ? Then try running
the browser.

Comment 8

[Sathiskumar Govindasamy]

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/run-mozilla.sh /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.

Comment 9

[Christopher Blizzard (:blizzard)]

Use the /usr/lib/mozilla-1.0.0/mozilla-rebuild-databases.pl script.

Comment 10

[Sathiskumar Govindasamy]

I executed that perl script and it didn't help either.

Comment 11

[Christopher Blizzard (:blizzard)]

Do you actually have a file called /usr/lib/libjsj.so?

--Chris

Comment 12

[Sathiskumar Govindasamy]

Till about mozilla-1.0rc3, the file libjsj.so 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

mozilla-chat-1.0.0-4
mozilla-mail-1.0.0-4
mozilla-psm-1.0.0-4
mozilla-1.0.0-4
mozilla-devel-1.0.0-4
mozilla-js-debugger-1.0.0-4
mozilla-nspr-devel-1.0.0-4
mozilla-nss-devel-1.0.0-4
mozilla-nspr-1.0.0-4
mozilla-dom-inspector-1.0.0-4
mozilla-nss-1.0.0-4


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

Now, libjsj.so 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/libjsj.so 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.

Comment 13

[hacker formerly known as [e-mail]]

The problem now sounds like a x-remote issue which I know the rpm scripts handle
differently than the tarball scripts. 
Over to Blizzard.

Comment 14

[Christopher Blizzard (:blizzard)]

Does openoffice have hooks into mozilla or something?  This is New Knowledge to
me if it does.

Comment 15

[Sathiskumar Govindasamy]

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
openoffice.org 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.

Comment 16

[Andrew Schultz]

I can reproduce this with the patched run-mozilla.sh 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
/usr/local/OpenOffice.org1.0/program

Comment 17

[Andrew Schultz]

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)

Comment 18

[Andrew Schultz]

arg!
==>XRemote

Comment 19

[Andrew Schultz]

Attachment: have XRemote accept xfeDoCommand secondary arguments

the patch could probably be cleaned up somewhat, but works.  the following work
properly:
mozilla -remote "xfeDoCommand(composeMessage)"
mozilla -remote "xfeDoCommand(composeMessage,attachment=file:///tmp/something)"

mozilla -remote
"xfeDoCommand(composeMessage,from=[e-mail],to=[e-mail])"

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).

Comment 20

[Andrew Schultz]

marking NEW

Comment 21

[Andrew Schultz]

the patch also makes it possible to open any folder from any mail/news account:

mozilla -remote "xfeDoCommand(openInbox,mailbox://[e-mail]/Drafts)"
            "xfeDoCommand(openInbox,news://[e-mail]/alt.os.linux)"

that doesn't seem particularly useful to me, but it's to be one of the lofty
objectives in bug 101169.

Comment 22

[Andrew Schultz]

*** Bug 204690 has been marked as a duplicate of this bug. ***

Comment 23

[Joe]

Attachment: update for the prior patch

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.

Comment 24

[Joe]

add cc

Comment 25

[Joe]

It would be really nice if the patch could be added when 1.4 released.
Anyone help to review?

Comment 26

[Henry Jia]

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.

Henry

Comment 27

[Dan Mosedale (:dmosedale, :dmose)]

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 @@
 }

 void
+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.

 nsresult
+XRemoteService::GetComposeLocation(char **_retval)
+{
+  // get the Compose chrome URL
+  *_retval =
nsCRT::strdup("chrome://messenger/content/messengercompose/messengercompose.xul
");
+
+  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
issue.

+  // 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.

Comment 28

[Joe]

Attachment: XfeDoCommand accept secondary Argument_2

Update the patch according to the points dmose mentioned.

Comment 29

[Dan Mosedale (:dmosedale, :dmose)]

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 sr=[e-mail].

Comment 30

[Joe]

Attachment: xfeDoCommand accept secondary arugments patch 3

put the if and then clauses on separate lines

Comment 31

[Joe]

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

Comment 32

[Antonio.Xu]

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 got=[e-mail]  

Comment 33

[Joe]

Attachment: xfeDoCommand accepts the secondary argument patch 4

revome the extra whitespaces and tabs.

Comment 34

[Asa Dotzler [:asa]]

Comment on attachment 123487 [details] [diff] [review]
xfeDoCommand accepts the secondary argument patch 4

This needs blizzard's review still.

Comment 35

[Christopher Blizzard (:blizzard)]

With this patch this works:

./mozilla -remote 'xfedocommand(composemessage
to=[e-mail],attachment=file:///tmp/test.txt)'

but this doesn't:

./mozilla -remote 'xfedocommand(composemessage,
to=[e-mail],attachment=file:///tmp/test.txt)'

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

openurl(http://www.mozilla.org,new-tab)
openurl(http://www.mozilla.org, new-tab)

and they work.  This would change that.

Comment 36

[Joe]

Attachment: xfeDoCommand accepts secondary argument.

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.

Comment 37

[Christopher Blizzard (:blizzard)]

Comment on attachment 123739 [details] [diff] [review]
xfeDoCommand accepts secondary argument.

r=blizzard

Seems to work pretty well and the code looks fine.  Thanks!

Comment 38

[Asa Dotzler [:asa]]

Comment on attachment 123739 [details] [diff] [review]
xfeDoCommand accepts secondary argument.

a=asa (on behalf of drivers) for checkin to 1.4

Comment 39

[leon.zhang]

checked into trunk