Bugzilla Bug 78890

Open Office resolves mozilla symlinks before invoking causing mozilla-launcher
to output unknown browser. This also happens when OOo is first installed and
sets the link for http documents to /usr/libexec/mozilla-launcher

There are a couple of solutions to this.
1)cp mozilla-launcher mozilla
2)change the /usr/bin/mozilla symlink to a hardlink

3) see attached patches
Note: introduces a new variable to /etc/rc.conf - $MOZILLALAUNCHER
this should be set equal to the mozilla progrem you want to run
eg firefox mozilla etc
it defaults to mozilla if not set

Reproducible: Always
Steps to Reproduce:
1.Install mozilla
2.Install OOo
3.Try to register from OOo help menu.
Actual Results:  
mozilla-launcher outputs unknown browser

Expected Results:  
mozilla-launcher starts configured mozilla application

Created an attachment (id=49079) [details]
Updates mozilla-launcher to pretend it was called as the contents of
$MOZILLALAUNCHER

Created an attachment (id=49081) [details]
Updates /etc/profile to export $MOZILLALAUNCHER from /etc/rc.conf or default to
"mozilla"

Created an attachment (id=49082) [details]
Updates /etc/profile to export $MOZILLALAUNCHER from /etc/rc.conf or default to
"mozilla"

Minor cosmetic change

I think that it would be better to fix this broken behaviour from openoffice
(possibly find out why it's done this way)

true, but I think the symlink problem with mozilla-launcher affects more than
just OOo, but OOo is a prime example. Maybe the bug should be assigned to
mozilla team?

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

There's no way I'd consider this a bug in mozilla-launcher.  It's unnecessary
and ridiculous for OOo to be resolving the symlinks itself instead of relying
on UNIX filesystem semantics.  I've never heard of any other respectable
program that.

This needs to be fixed in OOo

Well, this problem exist also in Poseidon for UML.  So this is probably more a
mozilla-launcher bug than you might admit.

A fix would probably be using the hardlink, but it would not work from mounted
filesystem (well, is /usr/bin and /usr/lib being different mount point exist in
the world?).

Leaving this as is, is a bug.

The patches included with this bug cause mozilla-launcher to launch a mozilla
app as specified in /etc/profile if it is called as 'mozilla-launcher'. This
default action is better than failing with an error, and is made flexable by
the fact that the default is user configurable.

Martin, I will not use the proposed patches in this bug.  No offense intended,
but they're a bad hack to workaround brokenness in OOo (and apparently another
broken application).  mozilla-launcher already has a transparent mechanism to
determine what browser should be called.  Adding another mechanism that breaks
the transparency and relies on users editing their environment to determine
their browser choice is not a good idea.

I will look into fixing OOo first.  If that fails, then I'll consider copying
instead of symlinking, though this requires quite a lot more work in the
post-install scripts to determine whether the copy is allowed to be moved or
updated.  The entire process needs to remain transparent.

As far as I'm concerned, whoever implemented this on OOo needs a whack with the
clue-bat

I probably should have emphisised that the patches were only intended as a
temporary solution for people to use until OOo and others are fixed.
I submitted them in the hopes that people would find them useful for that task.

Should this be an upstream bug for OOo?

Martin, in that case thanks for putting the patches in this bug.  Hopefully
they have been useful to somebody.

Regarding OOo, you may feel free to file a bug upstream.  Here are my thoughts
which might be helpful: Some programs act differently depending on how they are
named.  It is a common practice in UNIX to use a symbolic link to a program to
call it by a different name.  Other than mozilla-launcher, here are some more
examples:  bunzip2 -> bzip2, zcat -> gzip, rbash -> bash, ypdomainname ->
hostname, vim -> gvim.  The list goes on.  OOo's practice of resolving symbolic
links at the application level breaks programs relying on that behavior.

At this point I've committed new versions of mozilla-launcher, mozilla,
mozilla-firefox, mozilla-thunderbird, mozilla-bin, mozilla-firefox-bin, and
mozilla-thunderbird-bin.  These versions use a stub script in /usr/bin instead
of a symlink.  The stub sets MOZILLA_LAUNCHER which is honored by
mozilla-launcher-1.28.  Please give them a try and let me know how it goes.

If the fix doesn't work, please re-open this bug

Doesn't work, it adds ",new-" to the end of every URL.

Ah actually only when a firefox window is already open, it adds ",new-".  Lines
100 and 102 of mozilla-launcher cause this.

When a firefox window is NOT already open, the launcher works fine.

Changing lines 100 and 102 to this:
try_running "openURL($u)" || retval=$?

makes it work.  But then it's not using $MOZILLA_NEWTYPE, I'm not sure how that
is supposed to work.

Kenyon, fixed in 1.29 and 1.30

The wrapper scripts introduced for firefox and thunderbird introduce a breakage
that affects KDE users greatly i.e. we can no longer use *artsdsp* to obtain
sound in these applications - because artsdsp won't work for non-binaries.

Is this script still needed for OOo 2.x?