Summary: | Open Office resolves mozilla symlinks before invoking causing mozilla-launcher to output unknown browser | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Martin OConnor <martinoc> |
Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | askwar, fmouse-gentoo, kenyon, neil, office |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://forums.gentoo.org/viewtopic.php?t=212881&start=0&postdays=0&postorder=asc&highlight=mozillalauncher+unknown+browser | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Updates mozilla-launcher to pretend it was called as the contents of $MOZILLALAUNCHER
Updates /etc/profile to export $MOZILLALAUNCHER from /etc/rc.conf or default to "mozilla" Updates /etc/profile to export $MOZILLALAUNCHER from /etc/rc.conf or default to "mozilla" |
Description
Martin OConnor
2005-01-20 18:31:14 UTC
Created attachment 49079 [details, diff]
Updates mozilla-launcher to pretend it was called as the contents of $MOZILLALAUNCHER
Created attachment 49081 [details, diff]
Updates /etc/profile to export $MOZILLALAUNCHER from /etc/rc.conf or default to "mozilla"
Created attachment 49082 [details, diff]
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? |