Bug 212653
| Summary: | Firefox defaulting to unix _remote_exec -ish behavior | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Owen LaGarde <owen.m.lagarde> |
| Component: | firefox | Assignee: | Christopher Aillon <caillon> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.0 | CC: | tjb |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-10-04 14:34:27 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. Is there any way to disable this behavior? I've search the net everywhere and can't seem to find a way. This seems to work: sh -c "MOZ_NO_REMOTE=1 firefox -P default" 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. 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. |
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.