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

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

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

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

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)

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.

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.

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

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

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

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.

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

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

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

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)

arg! ==>XRemote

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=me@here.com,to=you@there.com)" 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

the patch also makes it possible to open any folder from any mail/news account: mozilla -remote "xfeDoCommand(openInbox,mailbox://ajschult@eos.ncsu.edu/Drafts)" "xfeDoCommand(openInbox,news://ajschult@news.ncsu.edu/alt.os.linux)" that doesn't seem particularly useful to me, but it's to be one of the lofty objectives in bug 101169.

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

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?

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

Update the patch according to the points dmose mentioned.

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=dmose@mozilla.org.

put the if and then clauses on separate lines

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

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=antonio.xu@sun.com

revome the extra whitespaces and tabs.

Comment on attachment 123487 [details] [diff] [review] xfeDoCommand accepts the secondary argument patch 4 This needs blizzard's review still.

With this patch this works: ./mozilla -remote 'xfedocommand(composemessage to=blizzard@mozilla.org,attachment=file:///tmp/test.txt)' but this doesn't: ./mozilla -remote 'xfedocommand(composemessage, to=blizzard@mozilla.org,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.

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 on attachment 123739 [details] [diff] [review] xfeDoCommand accepts secondary argument. r=blizzard Seems to work pretty well and the code looks fine. Thanks!

Comment on attachment 123739 [details] [diff] [review] xfeDoCommand accepts secondary argument. a=asa (on behalf of drivers) for checkin to 1.4

checked into trunk