Closed Bug 537355 Opened 15 years ago Closed 11 years ago

Linux Ubuntu 8.04 multiple screens with TWO separate x windows. if firefox running on 1 set of screens, it cannot be started on other set of x windows

Categories

(Firefox :: General, defect)

3.0 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: wb4alm, Unassigned)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.16) Gecko/2009121602 Ubuntu/8.04 (hardy) Firefox/3.0.16 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.16) Gecko/2009121602 Ubuntu/8.04 (hardy) Firefox/3.0.16 Ubuntu 8.04 LTS with Gnome. I have 4 monitors. 1 screen (900x1440) is defined as a separate X-window (with 4 desktops) from the other three screens (3840x1028) also defined as 4 desktops. If Firefox is running on any of the 3840x1028 desktops, it can not be started on any of the 900x1440 desktops. You get the "Firefox is all ready running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system." You can start as many additional windows on the 3840x1028 desktops as you want without the error message. If you start Firefox on the 900x1440 first, then the situation is reversed. no sessions can be started on the larger desktop, and you can start as many as you want on the smaller desktop. Apparently Firefox's "profile lock" does not take into consideration the fact that the program can be run from the same logon session from two different x-windows.... I need to be able to run firefox from both x-windows, as the smaller desktop screen is used to monitor remote processes that create HTML status messages, at the same time that the larger desktop is used as a normal work station. Reproducible: Always Steps to Reproduce: 1.Using a multiport display card, define a monitor to each of the ports. 2. In X-windows define the screens to be SEPARATE x-windows. (You will probably have to reboot your computer to do this.) 3. Start firefox on one monitor and look at anything. 4. Try to start firefox on the other monitor. You will receive the "Firefox is already running, but is not responding" error message. Actual Results: you can start as many session on whatever monitor you first used, but cannot start any sessions on the other monitor.. Expected Results: I should be able to use Firefox at the same time on either set of monitors without difficulty. It should not care that two different X-servers are being used as a single large desktop,
Problem also exists in Ubuntu 10.04 with Firefox 3.6.10
I have just seen this on Debian using the Iceweasel 3.5.16 and Epiphany 2.30.6 derivatives. The Debian Bug 200869 also covers an instance of this problem from July 2003 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=200869 To reproduce you will need a Debian machine with multiple displays configured as "Separate X screen" (two displays in my case). In my setup the first display is :0.0 and the second is :0.1 if on a terminal in either display I type the lines: epiphany --display :0.1 & epiphany --display :0.0 & only the first copy of epiphany will spawn on the correct display the second copy will be launched on the same display as the first. This is also the case when using the $DISPLAY system variable rather than the command line option. iceweasel behaves slightly differently in that iceweasel --display=:0.0 & iceweasel --display=:0.1 & Will spawn the first instance correctly but the second line brings up a prompt titled "Close Iceweasel" with the main test reading "Iceweasel is already running, but is not responding. To open a new window you must first close the existing Iceweasel process, or restart your system." I can run multiple lines of "iceweasel --display=:0.0 &" and as long as the only instance is on display :0.0 more will happily open; equally I can open many instances using "iceweasel --display=:0.1 &" if :0.1 is the only one with Icewaesl on it but I cannot open iceweasel on two separate x displays. Using TwinView rather than separate X screens does not have the problem but that is probably because when using TwinView X thinks everything is display :0.0 still.
Version: unspecified → 3.0 Branch
I was advised by someone that the work around for this is to specify separate profiles for each instance of iceweasel by using the -P <profile> option. It seems that only one instance of iceweasel can have read/write access to the profile at a time and starting a second instance will either fail or fall into some behaviour where you get another window on the same display because it is then the same instance reading the profile. epiphany also can use this work around but the --profile=DIR option must be used instead. I can only assume that the FireFox code will also work with this too but as I do not have a FireFox binary available to me at the office I cannot confirm this at present. I would suggest that in the very least the --display option gets a note in the man page saying that to run on multiple displays at the same time a unique -P [profile] value will be needed per display. Something like "May require -P [profile], see below." would be enough to give a user a hint at the work around. It might be better that a default profile is created for each display, but that would cause unexpected behaviour as profile settings would be different between the two displays without any explanation and I can imagine this causing more confusion than it is worth. Posting this work around to both https://bugzilla.mozilla.org/show_bug.cgi?id=537355 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=200869 so that things stay in sync as I am not yet sure which of the two is responsible for the quirky bit of code.
Can anyone reproduce this issue on a current Firefox version (23, 24 etc)?
Yes, this bug is still present in (at least) firefox 22 and 23 for Debian, CentOS and Gentoo. Oh, and this bug is a duplicate of #513506
This seems to be by design as per bug 513506 comment 1. There is no point in marking this as an enhancement since bug 513506 stays open, so closing as invalid.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Regarding Ioana's closure action: Bug 513506 is completely different. Bug 513506 is asking for the ability to open two windows that mirror each other. The poster said nothing about having the windows open on different X servers, he's talking about having one X server (or the Mac OS equivalent) with two monitors. This is a common configuration especially when giving presentations. Otherwise the poster's reproduction step "Move the window from one screen to another" wouldn't make sense. Stirling Westrup seems to have misunderstood bug 513506. His comment actually belongs on the present bug 537355. He also doesn't say anything about it being "by design" as claimed by Ioana. Thus Ioana used doubly invalid reasoning to close the present bug and mark it invalid. The present bug should be reopened. There are actually two parts to the present bug: - The same Firefox process can't open windows on different X displays. - As noted by Stirling Westrup, when you try to open a window on a different display, the error message you get ("Firefox is already running, but is not responding"), is erroneous and misleading The first problem might be difficult to fix, as different X displays may have different fonts, resolutions, and so on, which would need to be made non-global within the Firefox process. The second one should be easier, as it just involves detecting a particular situation when Firefox starts.
We're not going to add support for a single instance of Firefox running on multiple X servers. (I can't think of any other app that does something like that.) Firefox should "just work" on modern multi-head unix systems that abstract this away (it certainly did years ago with Xinerama). If it's not, that's a separate bug to file. Similarly, we're have no plans to support multiple instances of Firefox running from the same profile, on Linux or any other system.
I should point out that its not necessarily multiple X servers, but multiple video devices (which may or may not be on or more X servers). I currently work with Zero Clients for a living, so that might give me a somewhat unusual point of view. Zero Clients allow one to attach extra screens to a machine via USB or Ethernet. My current machine has 7 monitors, only one of which is run via the onboard graphics card. It is possible to write a single Xorg configuration that pulls all the necessary drivers into a single Xorg instance, and configures them, but as the world is moving away from explicit Xorg configuration files, most folks using Zero Client devices actually end up running one X instance per device. Most Linux display managers have no troubles creating a desktop that spans all these devices, whether they are in a single X instance or not, and I would *ideally* like to be able to drag a firefox window from one part of my desktop to another. Failing that, being able to open a firefox window on whichever desktop I want would also be convenient. As is, its quite difficult to manage to get a firefox to launch onto the correct monitor when using a unified desktop.
Thanks for the data, Justin. > I can't think of any other app that does something like that. Well most apps aren't as complex as Firefox. Of the X apps which even have a client-server model, I note that Urxvt can open a client on multiple X displays, no problem. Evince can do so, provided the files are different. Gimp doesn't like multiple displays and puts the second instance on the first display. Anyway, as I said it sounds like a difficult problem. I guess Mr. Westrup can have separate profiles for each display and sync them using the wonderful Firefox Sync tool :) ... (is separate profiles actually a workaround?) As for myself, I notice that killing firefox before starting it seems to work well, due to the auto-restore feature - I'm wandering between a desktop and a laptop in another room, and there's little need to keep Firefox windows open simultaneously on both. Peace.
I'll note for the record that Emacs handles this fine now too, i.e. remote frames across multiple servers (assuming "ssh -X ... emacsclient -c" is comparable). In any case, I just ran in to this problem when trying to connect to a remote system via xpra to open a new window on the existing Firefox process (one I didn't want to have to take down, since I'll want to use it normally when I return (physically) to that machine in a bit). Though perhaps in the upcoming Wayland world, all this will need to be handled differently anyway.
You need to log in before you can comment on or make changes to this bug.