122498 - -remote not finding running window

Status: RESOLVED INCOMPLETE

(Core Graveyard :: X-remote, defect)

Description

[Gregory Bond]

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     [e-mail]:/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.

Comment 1

[Christopher Blizzard (:blizzard)]

Are both mozilla processes running under the same username?

Comment 2

[Gregory Bond]

> 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.

Comment 3

[Christopher Blizzard (:blizzard)]

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.

Comment 4

[Gregory Bond]

Ripper.  I'll need to wait until a FreeBSD package of the 0.9.8 release and I'll
report back then.

Comment 5

[Gregory Bond]

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.

Comment 6

[Kevin Buhr]

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.

Comment 7

[Kevin Buhr]

Attachment: 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?

Comment 8

[Gregory Bond]

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!

Comment 9

[Jim Crumley]

Confirming due to comments from multiple users, adding patch keyword.

Comment 10

[Irwin Tillman]

Any idea if/when the patch will get integrated?

Comment 11

[Irwin Tillman]

patch fixes the problem for me on Solaris 8, X11 6.4.1, tvtwm patchlevell 11,
Mozilla 1.2b 2002-10-23.

Comment 12

[Jungshik Shin]

This bug seems to be still an issue in 1.6 and trunk. Does the patch fix the
problem on trunk? 

Comment 13

[Alan Schmitt]

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).

Comment 14

[Mikael Nilsson]

Reproducible with Firebird 0.7 and Firefox 0.8 on an up-to-date Debian unstable
with sawfish 1.3. 

 

Comment 15

[David Arnold]

this bug is still present in 1.6 (debian unstable), with tvtwm-pl11.
what has to be done to get the patch applied?

Comment 16

[Robert Bragg]

Attachment: 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?

Comment 17

[Jungshik Shin]

If you're confident of the patch, please ask for review and superreview.
Otherwise, nothing will happen. 

Comment 18

[Jungshik Shin]

Comment on attachment 154808 [details] [diff] [review]
Update of Kevin Buhrs old patch

asking for r/sr without specifying reviewers  would never work.

Comment 19

[Christopher Blizzard (:blizzard)]

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 20

[Jungshik Shin]

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.

Comment 21

[Robert Bragg]

Attachment: 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

Comment 22

[bugzilla]

The Patch don't work with the actuall SourceTree (Seamonkey 1.0a).

Can anyone port the Patch for the tree?

Comment 23

[Christopher Blizzard (:blizzard)]

Comment on attachment 155376 [details] [diff] [review]
update to address WM_STATE problem

-> caillon for review

Comment 24

[Benjamin Smedberg]

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.