Open
Bug 296363
Opened 19 years ago
Updated 2 years ago
x-remote doesn't aware hostname or IP
Categories
(Toolkit :: Startup and Profile System, defect, P5)
Tracking
()
REOPENED
People
(Reporter: ginnchen+exoracle, Unassigned)
References
Details
1) Consider we have 2 machines, HostA and HostB, both have a user with the same name. 2) Open a terminal in HostA, telnet to HostB in it and set DISPLAY to HostA:0.0, start mozilla on HostB 3) Open another terminal in HostA, try to start mozilla Expected Result: mozilla on HostA starts. Actual Result: The remote displayed mozilla on HostB opens a new navigator window.
Comment 1•19 years ago
|
||
This has bitten me badly a few times. Could we possibly fix this?
Comment 2•19 years ago
|
||
Isn't this working as designed? Perhaps MOZ_NO_REMOTE=1 is the answer?
Comment 3•19 years ago
|
||
> Isn't this working as designed?
The point is that the design is bad, imo.
MOZ_NO_REMOTE is a workaround, but I see the basic behavior as wrong.
Comment 4•19 years ago
|
||
Hmm... one could argue that the current design is nice. For example, if I have tbird running on one system and ffox running on another, but both are displayed on the same X display, then it is sort of nifty that I can click on links in tbird and have them render in the running instance of ffox.
Comment 5•19 years ago
|
||
I agree that it's nice in that case, but if I'm explicitly attempting to start firefox on some system, then it's odd to instead create a new window of an existing instance. Perhaps those should be different modes of operation for x-remote? That is, have an xremote flag that allows or disallows searching for things from other machines and set it appropriately?
Comment 6•19 years ago
|
||
Yeah, if we were to "fix" x-remote to only communicate with processes on the same X-client, then it would probably be a trivial addition to make that restriction optional.
I concur that this behavior is counter-intuitive and thus confusing. It continually causes me trouble.
Comment 9•17 years ago
|
||
Please let me is there any way to get a patch on this problem???
Comment 10•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•8 years ago
|
Status: RESOLVED → REOPENED
Component: X-remote → Startup and Profile System
Product: Core → Toolkit
Resolution: INCOMPLETE → ---
Updated•8 years ago
|
Assignee: blizzard → nobody
Priority: -- → P5
QA Contact: blizzard
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•