If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

-remote not finding running window




16 years ago
a year ago


(Reporter: Gregory Bond, Assigned: blizzard)



Firefox Tracking Flags

(Not tracked)



(2 attachments, 1 obsolete attachment)



16 years ago
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.

(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     toor@hellcat.itga.com.au:/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.

And of course no URL is opened.

Comment 1

16 years ago
Are both mozilla processes running under the same username?

Comment 2

16 years ago
> Are both mozilla processes running under the same username?


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

16 years ago
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

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

Comment 5

16 years ago
I've just updated to 
  Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020207 <developer

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

16 years ago
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

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

16 years ago
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?

Comment 8

16 years ago
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

16 years ago
Confirming due to comments from multiple users, adding patch keyword.
Ever confirmed: true
Keywords: patch

Comment 10

15 years ago
Any idea if/when the patch will get integrated?


15 years ago
Keywords: review

Comment 11

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

Comment 12

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

Comment 13

14 years ago
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

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


Comment 15

14 years ago
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

13 years ago
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?

Comment 17

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


13 years ago
Attachment #154808 - Flags: superreview?
Attachment #154808 - Flags: review?

Comment 18

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

asking for r/sr without specifying reviewers  would never work.
Attachment #154808 - Flags: superreview?(bryner)
Attachment #154808 - Flags: superreview?
Attachment #154808 - Flags: review?(blizzard)
Attachment #154808 - Flags: review?

Comment 19

13 years ago
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.
Attachment #154808 - Flags: review?(blizzard) → review-

Comment 20

13 years ago
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.
Attachment #154808 - Flags: superreview?(bryner)

Comment 21

13 years ago
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


13 years ago
Attachment #154808 - Attachment is obsolete: true


13 years ago
Attachment #155376 - Flags: review?(blizzard)

Comment 22

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

Can anyone port the Patch for the tree?

Comment 23

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

-> caillon for review
Attachment #155376 - Flags: review?(blizzard) → review?(caillon)

Comment 24

a year ago
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.
Last Resolved: a year ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.