Bug 114524 - mozilla launching xremote fix
mozilla launching xremote fix
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mozilla (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Blizzard
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-28 20:50 EST by Warren Togami
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-05-09 08:42:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Warren Togami 2004-01-28 20:50:28 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5)
Gecko/20031110 Firebird/0.7

Description of problem:
Below describes two broken xremote functions that our current
/usr/bin/mozilla script relies upon, and a method to fix the script
for equivalent functionality so that it works for mozilla-1.6+ and
MozillaFirebird-0.8+ while Thunderbird is running.  If you are running
an earlier mozilla or Firebird, then you must run
/usr/lib/thunderbird/mozilla-xremote-client rather than the browser's
own client or the browser will fail.

Please help to verify these findings and suggested patch to
mozilla-1.6.  Verify that there are no regressions in behavior, and it
behaves equivalently to before the patch both with and without
MozillaThunderbird-0.4 running.

Christopher Blizzard wrote:
> Warren Togami wrote:
>> Blizzard,
>>
>> Can we improve the /usr/bin/mozilla script to make it possible to 
>> launch while Thunderbird is running? It is currently impossible to do
>> so with the current /usr/bin/mozilla script. This may severely hinder
>> adoption of Thunderbird for Linux in the future.
>>
>> Do you already have a recipe to make this possible for 
>> /usr/bin/mozilla?
>
> If we're talking about the problem that I think we're talking about,
> Mozilla 1.6 should fix it.  The client in 1.6 (along with thunderbird 
> 0.4, I believe) include the code changes required to allow the client 
> to keep looking for a server that will support its request.
>
> --Chris
>

I did testing with mozilla-1.6-0 and fedora.us MozillaThunderbird-0.4,
and it appears that xremote behaviors are broken in several ways that
still make the /usr/bin/mozilla script fail while Thunderbird is
running with this thunderbird pop-up dialog:

Alert
Error launching browser window:TypeError:
Components.classes['@mozilla.org/appshell/component/browser/instance;1']
has no properties

There is a slight improvement over mozilla-1.4.1 and
MozillaFirebird-0.7 though, in that you no longer need to run
thunderbird's xremote client rather than the browser's xremote 
 in order to send the browser a signal.  This improvement is
unfortunately unrelated to the remaining xremote brokenness, which
currently make it impossible for the /usr/bin/mozilla script of 1.6 to
launch while Thunderbird-0.4 is running.

http://www.mozilla.org/unix/remote.html
Of the xremote commands listed on this page, these two commands in
mozilla-1.6 seem to be broken while Thunderbird is running:
ping()
xfeDoCommand (openBrowser)


function check_running() {
    $MOZ_CLIENT_PROGRAM 'ping()' 2>/dev/null >/dev/null
    RETURN_VAL=$?
    if [ "$RETURN_VAL" -eq "2" ]; then
      echo 0
      return 0
    else
      echo 1
      return 1
    fi
}

xremote's ping() functionality never works properly while Thunderbird
is running.  It normally returns "2" if Mozilla is not running, or "0"
if it is running.  While Thunderbird is running, ping() always returns
"0".  This leads the /usr/bin/mozilla script to think it needs to use
xremote rather than launch mozilla.

# check to see if there's an already running instance or not
ALREADY_RUNNING=`check_running`



# If there is no command line argument at all then try to open a new
# window in an already running instance.
if [ "${ALREADY_RUNNING}" -eq "1" ] && [ -z "$1" ]; then
  exec $MOZ_CLIENT_PROGRAM "xfeDoCommand(openBrowser)" 2>/dev/null
>/dev/null
fi


The xremote xfeDoCommand(openBrowser) option is what causes the pop-up
error dialog from Thunderbird mentioned near the top of this report. 
It seems that xfeDoCommand(openBrowser) is completely inoperable with
either Thunderbird's or mozilla-1.6's xremote client binary.

Since ping() is broken, we no longer have a functional way in which to
test for a running browser.  What other distributions have done to
workaround this problem are shell snippets like this:

$MOZ_CLIENT_PROGRAM "openURL($1,new-window)" && exit 0
# If the script reaches this line, then assume xremote failed
# launch mozilla directly

Unfortunately I have found that some programs like xchat call the
/usr/bin/mozilla script directly with parameters like "-remote
openURL(%s,new-window)", so the above snippet fails in that case. 
Below is a minimal patch to /usr/bin/mozilla that should work.

--- mozilla.orig        2004-01-21 06:50:01.633665318 -1000
+++ mozilla     2004-01-22 00:08:39.492016912 -1000
@@ -164,14 +164,18 @@
 # set our JVM vars
 set_jvm_vars

-# check to see if there's an already running instance or not
-ALREADY_RUNNING=`check_running`
-
-# If there is no command line argument at all then try to open a new
-# window in an already running instance.
-if [ "${ALREADY_RUNNING}" -eq "1" ] && [ -z "$1" ]; then
-  exec $MOZ_CLIENT_PROGRAM "xfeDoCommand(openBrowser)" 2>/dev/null
>/dev/null
+if [ "$1" == "-remote" ]; then
+    $MOZ_CLIENT_PROGRAM "$2" && exit 0
+else
+    URL="$1"
+    if [ -z $1 ]; then
+        URL="about:blank"
+    fi
+    $MOZ_CLIENT_PROGRAM "openURL($1,new-window)" && exit 0
 fi
+ALREADY_RUNNING=0
+# xremote failed, indicating that a browser is not already running
+# attempt to launch new browser

 # check system locale
 MOZARGS=


Version-Release number of selected component (if applicable):
mozilla-1.6-0
Comment 1 Warren Togami 2004-03-08 06:19:42 EST
Note that I have personally been running this in production on
multiple RH9, FC1, and FC2test machines for the past few months with a
mix of mozilla, MozillaFirebird-0.7, firefox-0.8, and thunderbird 0.4
and 0.5.  I am totally convinced that this workaround is better than
our current situation where the browser just FAILS while Thunderbird
is running, while not effecting non-thunderbird users.
Comment 2 James Henstridge 2004-03-10 00:09:07 EST
There is another trivial fix to the thunderbird problem that can be
solved without changing mozilla.

If you patch thunderbird to use different property names used for the
xremote communication (eg. _THUNDERBIRD rather than _MOZILLA),
mozilla/firebird will ignore thunderbird and vice versa.
Comment 3 Warren Togami 2004-03-10 03:26:31 EST
If Thunderbird is patched in that way, will clicking links in
Thunderbird still be able to launch a browser window in the existing
mozilla or firefox session?
Comment 4 James Henstridge 2004-03-10 04:01:13 EST
According to
http://www.mozilla.org/projects/thunderbird/linuxurls.html thunderbird
just executes a program to handle http links.

The only difference this change would cause is that firebird/mozilla's
mozilla-xremote-client program would not be able to open thunderbird
windows, and thunderbird's mozilla-xremote-client would not be able to
open mozilla/firebird windows.

When I was doing some work for ActiveState on Komodo a few years back,
they had a patch to do this sort of thing.  Since the changes are in
MPL covered files they have released the patch, and you shouldn't have
any licensing problems.

The changes made by Komodo can be found in the file
silo-mozilla-runtime.patch in
ftp://ftp.activestate.com/Komodo/MozillaPatches/mozilla-patches-ko25.zip
(it is a 4 line change to 3 files).
Comment 5 Warren Togami 2004-04-04 00:48:47 EST
http://bugzilla.mozilla.org/show_bug.cgi?id=237283
Blizzard has implemented permanent fixes that seem to work extremely
well, going into mozilla, firefox and thunderbird.

https://bugzilla.fedora.us/show_bug.cgi?id=1113
fedora.us thunderbird coming REAL SOON NOW.

Comment 6 Warren Togami 2004-04-21 17:35:33 EDT
Blizzard is it still in the plans to patch this before FC2 final?
Comment 7 Warren Togami 2004-05-09 08:42:03 EDT
Woo!  It has been included in FC2.

Note You need to log in before you can comment on or make changes to this bug.