Using the -remote switch cannot find the mozilla running on the local system. Using Netscape on a Solaris box to connect to the same mozilla process on the same X display works as expected. On the Solaris box: lightning$ uname -a SunOS lightning 5.6 Generic_105181-26 sun4u sparc SUNW,Ultra-60 lightning$ netscape -v Netscape Lite 4.79/U.S., 17-Oct-01; (c) 1995-2000 Netscape Communications Corp. lightning$ DISPLAY=hellcat:0 netscape -remote 'openURL(http://www.itga.com.au)' netscape: warning: both version 5.0 (0x3c027e9) and version 4.79 (0x3c0002b) are running. Using version 4.79. lightning$ (And the URL pops up as expected) On the FreeBSD box where mozilla is running: hellcat$ uname -a FreeBSD hellcat.itga.com.au 4.5-RC FreeBSD 4.5-RC #42: Wed Jan 23 16:31:46 EST 2002 email@example.com:/usr/obj/usr/src/sys/Hellcat i386 hellcat$ mozilla -version Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020102 <developer build> hellcat$ mozilla -remote "openURL(http://www.itga.com.au)" No running window found. hellcat$ DISPLAY=hellcat:0 mozilla -remote "openURL(http://www.itga.com.au)" No running window found. hellcat$ And of course no URL is opened.
Are both mozilla processes running under the same username?
> Are both mozilla processes running under the same username? Yep. Some additional testing has narrowed it down a bit - a colleague has the same Mozilla binaries and OS version, and it works for him. The difference might be in window managers - he uses Sawfish and I (being the dinosaur that I am) still use tvtw. (Hey it was good enough in 1991 it's still good enough now! One day, when I get a few free days, I'll upgrade my 10yo X config to use a newer WM :>) I'm happy to try any debugging tricks that might be helpful.
Oh, this might have been a bug that I fixed in the client right after 0.9.7 was released. Try one of the 0.9.8 snapshot builds to see if it has been fixed.
Ripper. I'll need to wait until a FreeBSD package of the 0.9.8 release and I'll report back then.
I've just updated to Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020207 <developer build> from the freeBSD port, and, under tvtwm, things are a little bit better. It works sometimes, maybe 1 try in 20. I cannot work out any reason why it works or doesn't. Once it starts working, it will keep working for a little bit until I change something (e.g. open a new window) when it will stop working again. I've tried vaious combos of - windows raised/iconified - one/multi windows open - on current/other virtual desktops - newly started mozilla vs been around a while with no obvious pattern yet. As before, I am happy to try any debugging tricks you might suggest.
I've observed the same problem under a Linux build of an April 14 pull of the 1_0_0 branch with the Enlightment window manager. The problem is that Mozilla searches the window tree as follows: for each child of the root window, it does a breadth-first search of the child's subtree until it finds the *first* window with the WM_STATE property. Then, it checks for the MOZ_VERSION property on that window and---if it doesn't find it---moves on to the next child of the root window. Some window managers, including Enlightment, can put multiple top-level client windows (each with a WM_STATE property) under a single child of the root window. Mozilla will only search a subset of these top-level WM_STATE windows and, depending on their order in the tree, may or may not find an already-running copy. While searching the window tree, Mozilla should only prune the children (and not the following siblings) of windows with the WM_STATE property. I'll start working on a patch, but it's not a one-liner because of the way the algorithm is implemented in XRemoteClient.cpp.
Created attachment 79945 [details] [diff] [review] patch to search for all top-level WM_STATE windows Okay, with this patch, FindWindow does a breadth-first search for WM_STATE windows, prunes their children from the search, and returns the first such window to have the correct "Mozilla properties". I haven't done extensive testing, but it worked on a window tree where the old version failed, and it seemed to work correctly with multiple windows running under different users. Gregory, can you see if this fixes your problem?
The patch fixes the problem for me. I'm using the FreeBSD port from 2002/03/20 which builds 0.9.9. Thanks a lot!
Confirming due to comments from multiple users, adding patch keyword.
Any idea if/when the patch will get integrated?
patch fixes the problem for me on Solaris 8, X11 6.4.1, tvtwm patchlevell 11, Mozilla 1.2b 2002-10-23.
This bug seems to be still an issue in 1.6 and trunk. Does the patch fix the problem on trunk?
I am also observing this bug: Linux charm 2.6.2-1mdk #1 Fri Feb 6 13:02:10 CET 2004 i686 unknown unknown GNU/Linux Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040217 Firefox/0.8.0+ enlightenment 0.16.6 It is reproducible most of the time (I guess it depends on the order that I open the windows in enlightenment).
Reproducible with Firebird 0.7 and Firefox 0.8 on an up-to-date Debian unstable with sawfish 1.3.
this bug is still present in 1.6 (debian unstable), with tvtwm-pl11. what has to be done to get the patch applied?
Created attachment 154808 [details] [diff] [review] Update of Kevin Buhrs old patch I have done some basic testing and it works for me. Hopfully we wont have to wait another 2 years before this bug gets attention again :) If someone wants to test and confirm the patch it might get added faster?
If you're confident of the patch, please ask for review and superreview. Otherwise, nothing will happen.
Comment on attachment 154808 [details] [diff] [review] Update of Kevin Buhrs old patch asking for r/sr without specifying reviewers would never work.
Comment on attachment 154808 [details] [diff] [review] Update of Kevin Buhrs old patch No, you can't just assume that WM_STATE is going to be set properly.
Comment on attachment 154808 [details] [diff] [review] Update of Kevin Buhrs old patch Robert, if you can address blizzard's concern, please do so and ask for r/sr once you fix that.
Created attachment 155376 [details] [diff] [review] update to address WM_STATE problem since WM_STATE can be unset on withdrawn windows I have updated the patch to not expect WM_STATE to be set. Though it still uses WM_STATE to optimise searching by not looking at their children. again I have done basic testing, and it works for me. I will request blizzard review the patch, but leave super review for now since I'm not sure at the moment who to ask. sorry about the mistake before with reviewing I hadn't read the Mozilla Hacker's Getting Started Guide
The Patch don't work with the actuall SourceTree (Seamonkey 1.0a). Can anyone port the Patch for the tree?
Comment on attachment 155376 [details] [diff] [review] update to address WM_STATE problem -> caillon for review
Mass resolving a bunch of old bugs in the x-remote component in preparation for archiving it. If this bug is still valid and useful, please move it to the "Toolkit: Startup and Profile System" component and reopen it.