I have mozilla-launcher-1.10 installed with mozilla-firefox-0.8-r3 Whenever I have firefox already running and I try to launch another instance it fails to detect the instance running and tries to start a new browser instance. This then causes the "Select User Profile" dialog to start, which then complains that I already have a running instance of my profile and won't start a new instance unless I create a new profile. I have traced the issue to the try_running function in the script. When the following line is executed with 'ping' as the argument: LOGNAME="${0##*/}-$LOGNAME" DISPLAY=$s $remote "$@" The mozilla-remote-client process returns an error value of 2 which indicates no currently running instances. If I change that specific line to: LOGNAME="$LOGNAME" DISPLAY=$s $remote "$@" It works as expected. However, since I don't fully understand how mozilla-remote-client works as the documentation is quite sparse, I'm not sure that I've truly resolved the issue. Additionally, I have tried re-emerging mozilla-firefox and continue to have the same issue. Reproducible: Always Steps to Reproduce: 1. emerge mozilla-firefox 2. start firefox 3. start firefox again Actual Results: The first instance of the browser started. The second instance brought up the "Select User Profile" dialog, which then complains that an instance with my profile is already running. Expected Results: The second instance should open a new window using the already running instance of the browser mozilla-firefox was emerged using the following: garath root # equery -q -C uses mozilla-firefox [ Colour Code : set unset ] [ Legend : (U) Col 1 - Current USE flags ] [ : (I) Col 2 - Installed With USE flags ] U I [ Found these USE variables in : net-www/mozilla-firefox-0.8-r3 ] + + java : Adds support for Java - - gtk2 : Use gtk+-2.0.0 over gtk+-1.2 in cases where a program supports both. - - ipv6 : Adds support for IP version 6 - - gnome : Adds GNOME support - - moznoxft : Disable XFT support in and/or firefox + + truetype : Adds support for FreeType and/or FreeType2 fonts - - xinerama : Add support for XFree86's xinerama extension, which allows you to stretch your display across multiple monitors Portage 2.0.51_pre9 (default-x86-2004.0, gcc-3.3.3, glibc-2.3.3_pre20040420-r0, 2.6.5-gentoo-r1) ================================================================= System uname: 2.6.5-gentoo-r1 i686 Intel(R) Pentium(R) 4 CPU 1.80GHz Gentoo Base System version 1.4.15 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.3 Binutils: sys-devel/binutils-2.14.90.0.8-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache fixpackages sandbox" GENTOO_MIRRORS="http://gentoo.mirrors.pair.com/ http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acpi alsa arts artswrappersuid avi berkdb cdr crypt cups dvd encode fam fbcon foomaticdb gdbm gif gpm gtk gtk2 imlib java javascript jpeg kde libg++ libwww mad mbox mikmod mmx motif mozilla moznocompose moznoirc moznomail mpeg ncurses nls nptl oggvorbis opengl pam pda pdflib perl png ppds python qt quicktime readline sasl sdl slang spell sse ssl svga tcltk tcpd tiff truetype usb x86 xml2 xmms xv zlib linguas_en"
Hi Paul! Thanks for the very complete bug report. That's very helpful. Would you mind doing the following? 1. start firefox 2. run the following command bash -x /usr/bin/firefox http://google.com/ &>firefox.out 3. attach firefox.out to this bug Thanks!
Created attachment 32331 [details] Debug output from firefox
Paul, that's strange, mozilla-launcher couldn't find an instance of the browser that's owned by your username! How about attaching the output of xwininfo -root -tree Thanks
Created attachment 32360 [details] Ooutput from xwininfo -root -tree
Since it looks like we might be getting into the realm of X here. I'm running x11-base/xorg-x11-6.7.0 It was emerged using the following: garath root # equery -C -q uses xorg-x11 [ Colour Code : set unset ] [ Legend : (U) Col 1 - Current USE flags ] [ : (I) Col 2 - Installed With USE flags ] U I [ Found these USE variables in : x11-base/xorg-x11-6.7.0 ] - - 3dfx : Adds support for 3dfx video cards to XFree86. See: voodoo3 - - 3dnow : Adds support for 3dnow multimedia processor instructions - - cjk : Adds support for Multi-byte character languages (Chinese, Japanese, Korean) - - debug : Tells configure and the makefiles to build for debugging. Effects vary acrosss packages, but generally it will at least add -g to CFLAGS. Remember to set FEATURES+=nostrip too. - - doc : Adds extra documentation (API, Javadoc, etc) - - hardened : activate default security enhancements for toolchain (gcc, glibc, binutils) - - ipv6 : Adds support for IP version 6 + + mmx : Adds support for optimizations for Pentium MMX and Athlon class processors + + nls : unknown + + pam : Adds support PAM (Pluggable Authentication Modules) - - pie : Enable support for Position Independent Executables - - sdk : unknown + + sse : fast floating point optimisation for Pentium class chips - - static : !!do not set this during bootstrap!! Causes things to be statically linked instead of dynamically
Created attachment 32454 [details] debugging firefox script Paul, you might be right, it might be an xorg-x11 conflict with mozilla-launcher. Here is a debugging version of firefox (the mozilla-launcher script) which outputs the X properties of each window it investigates. Would you try this, collect the output, and attach it? You can obsolete the old debug output. Thanks (and sorry for all the bother)
I will have the output attached later on this evening (when I get home from work). It is definitely looking like something with my xorg-x11 install as I just tried to VNC into the box from work and running under VNC, it worked correctly.
Created attachment 32498 [details] Output from debugging script
I ran some more tests and I discovered that it actually will fail using vnc as well. The reason that it worked earlier with vnc was my display was set to hostname:display and the script was considering it to be a remote host. When I reset my display to be :display under vnc, it exhibited the same behavior.
Well, it's pretty strange. I don't see why it should be exhibiting this behavior under xorg-x11 any more than xfree. Anyway, you can work around the problem by setting MOZ_NO_FAKE_USER=1 in your environment, or you can update to mozilla-launcher-1.11. Thanks for your willingness to debug. :-)
I updated to mozilla-launcher-1.11 and it appears to be working correctly. Thanks for the effort.
Paul, I had to revert this change in mozilla-launcher-1.12 because it breaks things for other people. Here is the ChangeLog entry: *mozilla-launcher-1.12 (08 Jun 2004) 08 Jun 2004; Aron Griffis <agriffis@gentoo.org> -mozilla-launcher-1.11.ebuild, +mozilla-launcher-1.12.ebuild: Revert previous change. The problem is that mozilla-xremote-client will deliver a command to the wrong target (for example thunderbird instead of firefox) unless fake_user is employed. This means that mozilla-launcher-1.11 will fail to start a new instance of firefox if it finds an instance of thunderbird because fake_user failed. Instead the only solution to bug 52364 at the moment is to set MOZ_NO_FAKE_USER=1 in the environment. So at this point you will need to set MOZ_NO_FAKE_USER=1 in your environment to work around the problem on your system. By the way, I'm running xorg-x11 now and don't have the same problem you're seeing... Of course the ultimate fix to the problem is for mozilla-1.7, firefox-0.9 and thunderbird-0.7 to be released so that mozilla-xremote-client supports the -a flag.
Thanks, I've updated my environment. Even though there is a work around, it sounds like this is something that will eventually be fixed upstream, so I was wondering if it would make more sense to change the resolution to upstream?
Maybe, but I don't quite understand the meaning of RESOLVED-UPSTREAM. It isn't resolved there yet, we don't have a new version yet, and we're not filing bugs about it because it's fixed in their cvs. So I'll just leave it FIXED
Final note: I just emerged mozilla-firefox-0.9-r1 and the problem is completely resolved with the -a flag to mozilla-xremote-client.
