Bug 212653 - Firefox defaulting to unix _remote_exec -ish behavior
Firefox defaulting to unix _remote_exec -ish behavior
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: firefox (Show other bugs)
4.0
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-27 16:51 EDT by Owen LaGarde
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-04 10:34:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Owen LaGarde 2006-10-27 16:51:53 EDT
Description of problem:

   With the display on a remote system redirected to the local system, and
   a local xhost allowance for the redirect, a remote CLI 'firefox'
   produces a browser instance on the remote system only when no such
   browser instance exists on the local system, i.e., local to the X server
   to which all display is currently directed.  When a local instance is
   already running, the command run on the remote system results in a new
   instance on the local system, not the remote system where the command
   was run.

Version-Release number of selected component (if applicable):

   firefox-1.5.0.7-0.1.el4

How reproducible:

   Setup:

   - close all instances of firefox on both systems
   - log into host "gilgamesh"
   - ssh (with x tunnel support) or rlogin/telnet
     (needs xhost) to bloodstone3 from gilgamesh
   - start firefox via CLI on gilgamesh, set home
     page to google, set ask-then-clear-on-exit
     for all user data, exit firefox
   - start firefox via CLI on bloodstone3, verify
     default home page (en_mozilla), verify no
     ask-then-clear-on-exit for any user data,
     exit firefox
   - verify no firefox process on either system

   Scenario 1:

   Issue the following on gilgamesh:

      $ strace firefox >scenario_1.gilgamesh.2006-10-12.txt 2>&1

   then issue the following on bloodstone3:

      $ strace firefox >scenario_1.bloodstone3.2006-10-12.txt 2>&1

   Two browsers open, both to google.  The command on
   bloodstone3 returns to prompt immediately and no 
   'firefox' process exists on bloodstone3.  Three
   processes exist on gilgamesh:  the shell wrapper
   'firefox', the shell wrapper 'run-mozilla.sh', and
   the binary 'firefox-bin'.  The command on gilgamesh
   does not return to prompt.

   Close both browsers.

   The command on gilgamesh returns to prompt.  Firefox
   opens a query panel to ask about clearing of user
   data.


   Scenario 2:

   Issue the following on bloodstone3:

      $ strace firefox >scenario_2.bloodstone3.2006-10-12.txt 2>&1

   then issue the following on gilgamesh:

      $ strace firefox >scenario_2.gilgamesh.2006-10-12.txt 2>&1

   Two browsers open, both to mozilla.  The command on
   gilgamesh returns to prompt immediately and no
   'firefox' process exists on gilgamesh.  Three
   processes exist on bloodstone3:  the shell wrapper
   'firefox', the shell wrapper 'run-mozilla.sh', and
   the binary 'firefox-bin'.  The command on bloodstone3
   does not return to prompt.

   Close both browsers.

   The command on bloodstone3 returns to prompt.  Firefox
   does not ask about clearing of user data.

Actual results:

   Browser instances and processes spawn on local or remote
   systems as dictated not by where they are requested to
   launch but by whether other instances are pre-existing.

Expected results:

   A request to start firefox on the local system should result
   in processes on the local system, and vice versa for requests
   on a remote system, regardless of whether or where X widgetry
   is directed.

Additional info:

   Further documentation in RHN service request 1054136.
Comment 1 Owen LaGarde 2006-10-27 16:56:52 EDT
NOTE that this issue is independent of the X widgetry transport mechanism;  it
is reproducable using *any* mechanism which causes the local and remote X
servers to be visible to each other.  Using rlogin/telnet/rsh with xhost has the
same results as using ssh with X11 tunnels and no xhost.
Comment 2 Thomas J. Baker 2007-09-06 19:43:22 EDT
Is there any way to disable this behavior? I've search the net everywhere and
can't seem to find a way.
Comment 3 Thomas J. Baker 2007-09-09 19:15:47 EDT
This seems to work:

sh -c "MOZ_NO_REMOTE=1 firefox -P default"
Comment 4 Owen LaGarde 2007-09-10 17:53:07 EDT
Any idea when MOZ_NO_REMOTE was added?  I can't seem to find it in any of the
changelogs.  It does work, though.  Kludgey, but certainly better than a sharp
stick in the eye....  I still fail to see why attachment to a remote instance is
default behavior, but meh, at least there's a work-around.
Comment 5 Christopher Aillon 2007-10-04 10:34:27 EDT
Ah, I had forgotten about that flag as I don't use it much (I do vnc instead). 
This was added upstream during the betas for Firefox 1.5.
https://bugzilla.mozilla.org/show_bug.cgi?id=289383 has the nitty gritty on it
if you're interested.

As this is the intended behavior, and it would be even more kludgy to differ
from upstream here, I'm going to mark this as WONTFIX.

Note You need to log in before you can comment on or make changes to this bug.