Closed
Bug 122498
Opened 23 years ago
Closed 8 years ago
-remote not finding running window
Categories
(Core Graveyard :: X-remote, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: gnb, Assigned: blizzard)
Details
Attachments
(2 files, 1 obsolete file)
6.76 KB,
patch
|
Details | Diff | Splinter Review | |
7.22 KB,
patch
|
Details | Diff | Splinter Review |
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 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. hellcat$ And of course no URL is opened.
Assignee | ||
Comment 1•23 years ago
|
||
Are both mozilla processes running under the same username?
Reporter | ||
Comment 2•23 years ago
|
||
> 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.
Assignee | ||
Comment 3•23 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.
Reporter | ||
Comment 4•23 years ago
|
||
Ripper. I'll need to wait until a FreeBSD package of the 0.9.8 release and I'll report back then.
Reporter | ||
Comment 5•23 years ago
|
||
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•22 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 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•22 years ago
|
||
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?
Reporter | ||
Comment 8•22 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•22 years ago
|
||
Confirming due to comments from multiple users, adding patch keyword.
Comment 10•22 years ago
|
||
Any idea if/when the patch will get integrated?
Comment 11•22 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•21 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•21 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•21 years ago
|
||
Reproducible with Firebird 0.7 and Firefox 0.8 on an up-to-date Debian unstable with sawfish 1.3.
Comment 15•20 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•20 years ago
|
||
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•20 years ago
|
||
If you're confident of the patch, please ask for review and superreview. Otherwise, nothing will happen.
Updated•20 years ago
|
Attachment #154808 -
Flags: superreview?
Attachment #154808 -
Flags: review?
Comment 18•20 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?
Assignee | ||
Comment 19•20 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•20 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•20 years ago
|
||
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
Updated•20 years ago
|
Attachment #154808 -
Attachment is obsolete: true
Updated•20 years ago
|
Attachment #155376 -
Flags: review?(blizzard)
Comment 22•19 years ago
|
||
The Patch don't work with the actuall SourceTree (Seamonkey 1.0a). Can anyone port the Patch for the tree?
Assignee | ||
Comment 23•19 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•8 years 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.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Updated•5 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•