144674 - Moz Remote Commands fail if a drop down listbox is open

Status: RESOLVED INCOMPLETE

(Core Graveyard :: X-remote, defect)

Description

[Michael Petch]

If you issue a mozilla remote command to a browser that currently has a drop
down list box currently open, the next moz remote request will hang.

If you cancel the moz remote command that hangs, each request after that will
siply fail. Old version of moz-remote actually give an error that there is a
semaphore lock.

The problem disappears if the browser is closed and restarted, as well it seems
to fix itself if you open a new browser (from the GUI).

To reproduce, create a bash script (or any script) that is equivalent to the
following:

while [ 1 ]; do
   mozilla -remote 'ping()'
   echo $?
   sleep 3
done

With this script written, and save... first  close all copies of mozilla running
on your desktop. Run mozilla from the command line and put it in the background, IE:

mozilla &

now that mozilla is on your desktop, execute the script you wrote above. When
this script is workign properly it should display 0 every few seconds when a
remote ping is successful.While the script continues to run, pull down a list
box (you cna navigate to any site with a drop down list box, or you can pull
down the list box of the URL bar).

Now once you pull it down don;t slect anything. Just let it stay open for 5
seconds. Now look at the output of the script thats running. It will appear to
hang and not return at all (The output of 0's stops). Now close the list box.
Notice how the script is still stuck.

Stop the script (with control-c), but keep the browser up (with no list box
open), and you should find the script says the command failed, and the value 1
is returned. It will continue to do this until you either open a new browser
window, or close the browser and start a new one up.

I consider this a major problem. It seems to exist all the way back to M18 (I
didn't test earlier versions). We have a product that remotely controls mozilla
using this feature. For a year or more we had this "non reproducible" hang on
the remote call. Eventually we managed to reproduce it by pulling down a list box.

Any product that has the intention of using mozilla remoteX (even the stand
along client does the same thing) will encounter this issue. Presently the only
way around it is to kill the browser and restart it (which is a poor workaround
from the enduser perspective). 

I tried doing similar tests on Netscape 4.78, and it appears to work. I don;t
know about Netscape 6.x.

Mike Petch

Comment 1

[Michael Petch]

A corerction to my original report. The paragraph that said this:

Stop the script (with control-c), but keep the browser up (with no list box
open), and you should find the script says the command failed, and the value 1
is returned. It will continue to do this until you either open a new browser
window, or close the browser and start a new one up.

Should have read:

Stop the script (with control-c), but keep the browser up (with no list box
open). RESTART the script and you should find the script says the command
failed, and the value 1 is returned. It will continue to do this until you
either open a new browser window, or close the browser and start a new one up.

Comment 2

[Andrew Schultz]

marking NEW

the client hangs at XNextEvent waiting for a proper response from the browser.

the browser window never makes it into
nsGtkMozRemoteHelper::HandlePropertyChange (even after the listbox is closed).

subsequent attempts to use the client fail because the first attempt set the
lock and it was never removed.

Comment 3

[Andrew Schultz]

This also happens if you have a menu pulled down or a context menu popped up. 
Perhaps those are grabbing the event so the XRemoteClient server never sees it.

anyway, I stole the code that the client uses to wait for a lock and had it wait
for events.  That "fixes" the problem on the client side -- the client doesn't
hang forever and removes the lock when it's done so further attempts will work.

Comment 4

[Andrew Schultz]

Attachment: patch

allows client to timeout waiting for server response.

Comment 5

[Andrew Schultz]

This is gtk1-only.  gtk1 is dead on trunk

Comment 6

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