Feature Request: Allow Firefox to work on multiple X11 screens

This was fixed ages ago, dont file bugs with older builds please

*** This bug has been marked as a duplicate of 245418 ***

If you'd actually bothered to read beyond the first sentence of my bug, Jose, you would have seen that it is NOT a duplicate of the old one.
This bug exists on 1.5 also.

Duplicate of/related to bug 285954?

I can confirm this bug. I'm running Firefox 1.5.0.1 in Fedora Core 4. If I already have Firefox running on display 0:0, then type 'firefox' in a terminal on display 0:1, I get the following error dialog message:

"Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system."

This also occurs when I click a link from Thunderbird running on display 0:1 with Firefox running on display 0:0 (see bug 236647, comment 6).

I can also confirm this bug. Exact same response for me in Gentoo. In addition if I try to force the X display (using --display) then I get the "Choose User Profile" dialog box.

This bug still persists in 1.5.0.6 on a windows XP machine with SP2 and Dual monitors.

Reproduction:
1. Open FF
2. move to second monitor and maximize the window
3. browse
4. close FF
5. open FF agian, it will pop up maximized on the first monitor.

What's worse, I used to be able to open multiple mozillas on :0.0 and :0.1. Now seamonkey has the exact same issue that firefox has. When I open a seamonkey on :0.1 I cannot open another seamonkey on :0.0. The new instances always launch on :0.1.

ok ... confirming.

*** Bug 330781 has been marked as a duplicate of this bug. ***

Comment #6 is bug 264030

This bug persists into the 2.0.0.* firefoxes too...
Perhaps someone thinks it's a feature? It's not!
:)
Thanks!
je_fro

Confirming that this is still present in 2.0.0.5. I would really like this issue to be resolved.

This bug is also present in Minefield (3.0a9pre), I'm willing to test patches..

Or at least tell me where in the code I should start looking and hacking, maybe I'll be able do come up with something.

I'd imagine you want to look under mozilla/widget/src somewhere, possibly http://lxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsWindow.cpp

I'm a Windows user and not familiar with this part of the code, so I can't really help you much more than that.

The error ("Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox, or restart your system.") appears because FF can't lock the profile. Why that is I don't know.

http://lxr.mozilla.org/seamonkey/source/toolkit/xre/nsAppRunner.cpp#2861

SelectProfile(), tries to lock the profile and if that fails then it calls ProfileLockedDialog() which displays the error (both functions are defined in the same source file).
But I didn't find the code that kicks in when FF sees that an instance is already running and connects to it (I suppose such code exists so that FF can avoid trying to lock the profile twice).

How can I profile FF? Is there something like strace so I could see which functions are being called?

Created attachment 287156
Fix XRemoteClient to support multiple screens

The problem is that XRemoteClient only scanned the default screen of the display. So if there's already a FF window open on screen 0 and you start firefox with DISPLAY=:0.1, the second instance won't see the first one and then try to lock the profile which than fails.

This patch fixes XRemoteClient to first scan the default screen and if no FF window is found it scans all other screens.

This fixes the inability to open links (from Thunderbird for example) if FF is running on a different screen. But I still don't know how to convince FF to open a new window on a different screen (so that you can have a FF window on each screen using the same profile). Any suggestions are welcome (probably need to extend the 'remote'-protocol to transmit the screen number on which the user wants to have the window opened?)

Comment on attachment 287156
Fix XRemoteClient to support multiple screens

Requesting review from caillon and roc on your behalf. :)

Requesting wanted1.9.

Comment on attachment 287156
Fix XRemoteClient to support multiple screens

asac, could you take a look at this? bsmedberg recommended you as a reviewer. :)

Still leaving r?caillon in case he gets around to it. Replaced roc with bsmedberg, as per roc's request.

i am at a conference and will take a look asap ... at latest coming weekend.

Comment on attachment 287156
Fix XRemoteClient to support multiple screens

>+ // First we check whether there is a window on the default screen
>+ w = FindBestWindow(aProgram, aUsername, aProfile, aSupportsCommandLine,
>+ defaultScreen);
>+ if (w)
>+ return w;
>+
>+ // If not, then check all other screens
>+ for (i = 0; i < numScreens && i != defaultScreen; ++i) {
>+ w = FindBestWindow(aProgram, aUsername, aProfile, aSupportsCommandLine,
>+ i);
>+ if (w)
>+ return w;
>+ }

This above loop isn't quite right. If we have screens 0, 1, and 2, with 1 being the default and a window on 2, we won't find it. The defaultScreen check likely should be contained in the loop itself with a continue statement.

That said, I'm rather puzzled as to how this patch fixes this bug? I can't seem to see how it would allow opening windows on multiple screens. I think the reporter can work around his problem by running firefox with MOZ_NO_REMOTE=1 (or whatever that env var is called) in addition to the DISPLAY= magic and set up differing profiles.

(In reply to comment #22)
> This above loop isn't quite right. If we have screens 0, 1, and 2, with 1

Err, what was I thinking.. that's obviously wrong, will fix that in a later patch.

> That said, I'm rather puzzled as to how this patch fixes this bug? I can't
> seem to see how it would allow opening windows on multiple screens. I think
> the reporter can work around his problem by running firefox with
> MOZ_NO_REMOTE=1 (or whatever that env var is called) in addition to the
> DISPLAY= magic and set up differing profiles.

$ MOZ_NO_REMOTE=1 DISPLAY=:0.1 firefox

still throws that error. Part of the explanation why that happens in in comment #16. Every new instance of FF will first try to use xremote and if that fails than it goes on and tries to lock the profile. Without my patch, FF can't find a running FF and goes kaboom when it tries to lock the profile because the other instance has it locked already.
And in comment #17 I explained that the patch doesn't fix the bug fully, but only part of it, enough to make FF usable with multiple screens (at least clicking links works from both screens).

Fixing the bug wholly is IMHO very difficult, because it would either require two separate FF instances to lock the profile simultaneously. Or it would require a rewrite of the gtk/x11 UI code to not rely on get_default_screen/display etc. and use the screen/display that the user passes to it through xremote (like: FF running on screen 0, user executes firefox on screen 1, it passes the command and DISPLAY=.1 to the running instance and that makes sure that the new window opens on screen 1).

Whoops, it's -no-remote now (Bug 325509). And yes you would need to use a different profile, regardless. But this is the workaround that many people who want to run firefox on multiple displays (usually via SSH tunneling) get it to work.

(In reply to comment #24)
> Whoops, it's -no-remote now (Bug 325509). And yes you would need to use a

Doesn't work with it either.

> different profile, regardless. But this is the workaround that many people who
> want to run firefox on multiple displays (usually via SSH tunneling) get it to
> work.

Can someone roughly asses how much work it would be to properly implement multi-screen support? Maybe it would qualify as a SoC project?

*** Bug 403130 has been marked as a duplicate of this bug. ***

*** Bug 364306 has been marked as a duplicate of this bug. ***

*** Bug 285954 has been marked as a duplicate of this bug. ***

Comment on attachment 287156
Fix XRemoteClient to support multiple screens

please request sr once asac or caillon give r+

Do I need to upload an updated patch (see comment #22) before this patch is approved? I was hoping I could wait until all the relevant people post their thoughts.. in case there are other objections.

(In reply to comment #30)
> Do I need to upload an updated patch (see comment #22) before this patch is
> approved? I was hoping I could wait until all the relevant people post their
> thoughts.. in case there are other objections.

You might as well post a new patch. Gives people less reasons to object. :)

Created attachment 290194
 Fix XRemoteClient to support multiple screens (try 2)

Fixed the issue that is outlined in comment #22.

I guess that this sort of hinges on which of these two behaviors is better:

* present an error instead of opening a firefox window
* open a firefox window on a completely different screen that the user may not be aware of.

The patch will lead to the latter, and I'm not sure this is any better in the long run. I believe it will lead to more confusion as people keep trying to open windows and firefox "silently" does nothing. They might not realize the window is opening on the other screen. We should definitely fix this the right way by supporting multiple screens. Until then, maybe we can simply provide a more useful error message?

(In reply to comment #33)
> I believe it will lead to more confusion as people keep trying to
> open windows and firefox "silently" does nothing. They might not realize the
> window is opening on the other screen.

Metacity will move the FF window to the current workspace if you click a link in thunderbird or gnome-terminal. And compiz will switch the workspace to the one where the FF window is. I don't know how the other WMs behave, but it seems like FF does its best to make itself visible after you open a link and the window isn't in the current workspace.

This just seems like a bad workaround, it won't solve to problem at all. How difficult would it be to properly fix this bug (as proposed in comment #23)?

(In reply to comment #35)
> This just seems like a bad workaround, it won't solve to problem at all.

Some people want to have one FF window and open all links in that, others want to have one FF window on each screen. The only 'proper' solution would be to make it highly configurable. Or, if that's not possible, choose one way which the majority of users prefer and upset the other users.

I actually don't see my patch as a 'bad workaround' as it could co-exist with a proper fix that allows multiple FF windows on independent screens. Don't get me wrong, I'd love to fix this properly, but as I see it (university courses + the complexity of a proper fix + getting accustomed to the mozilla development process + ...) I probably won't have time to do that before the 3.0 release (assuming the 'late 2007/early 2008'-roadmap still holds).

Right now FF's usability on multi-screen displays is severely impacted. I see my patch as an intermediate step between now (3.0?) and a proper fix sometime in the future (3.1/3.5?).

Christopher, you can't easily display a special error dialog because there's nothing special in the way how FF fails to start. From FF's point of view the profile is locked and it doesn't know why that is. One way to solve that would be to detect the FF instance on another screen, propagate that back and then fail with a special error dialog. Though I have to say I don't like that solution - why should FF fail if it already detects a running FF instance?

The point is, this patch does not fix this bug as reported. You are still not able to have the same Firefox profile running on two screens.

The secondary point to consider then is this a good intermediate step? I don't believe so. Don't get me wrong. I think this patch is great in general, and when we support multiple screens properly we should take this. But as an intermediate step I believe it will cause _more_ confusion than now. Having windows open in a different screen is not intuitive at all. More likely than not there will be people that start firefox, and nothing appears to happen. So they try again. And again. And it just appears broken, without them knowing there are a bunch of other windows on a different screen. I'm not saying I like the current behavior. But fixing this bug halfway does not seem like a viable option, either. We should fix it fully.

You second point is valid. But let me explain something. I don't see any conceptual difference between having multiple workspaces and multiple X screens. So if a user has FF in one workspace and Thunderbird in a second, clicks a link in Thunderbird and FF (for some reason, see later) doesn't steal focus, the user will be equally confused. So the whole user experience goes and falls with FF's ability to steal focus and make itself visible if the user opens a link.
If FF doesn't steal focus, and the user isn't aware that he has multiple workspaces, he will never find the FF window. Equally, if the user isn't aware that he has multiple screens, and FF won't steal focus, he won't find the FF window either. And I think you'll agree with me that it's more likely that a user (who, for example, comes from the MS world to Linux) isn't aware of workspaces than a user not being aware that he has multiple screens (imagine that!).
I don't know whether the focus stealing is configurable or not, because it has happened to me more than once that I clicked a link and FF _didn't_ steal focus, and I then was confused because FF was already running in a different workspace! Maybe it was a bug or some other reason, but it definitely wasn't nice. Someone familiar with the 'focus stealing' code could shed some light onto how FF behaves in that regard.

To your first point, it's hard to now decide what the proper fix is. Some users should come up and comment on how they want FF to behave. I thought about openURL(new-tab|new-window) and adding new flags like same-display, default-display or display=:0.1 etc to allow flexibility. I definitely would miss the feature that FF uses the existing window even if it's on a different screen!

(In reply to comment #38)
> To your first point, it's hard to now decide what the proper fix is. Some users
> should come up and comment on how they want FF to behave. I thought about
> openURL(new-tab|new-window) and adding new flags like same-display,
> default-display or display=:0.1 etc to allow flexibility. I definitely would
> miss the feature that FF uses the existing window even if it's on a different
> screen!
>

When trying to open a window on a second screen I would except to get a window there using the same profile as the first screen (I believe this means two screens sharing the same instance). Actually, some sort of flag to define the behaviour would be great, especially when it comes to opening links!

I believe that the attached patch _is_ an improvement (links in Thunderbird for instance). However, it does _not_ solve this bug at all.

Also, Fluxbox won't switch focus to the workspace when a link is opened, it won't even focus Firefox at all! (But I don't consider that an issue)

My $0.02:
I would want firefox to launch on the same screen you're using when you clicked that link, the icon, or manually launched via the command line.

Here's a simple example of how I use multiple screens, and how I expect Firefox to behave.

Most of the time, I have a Firefox window open on the centre monitor (usually :0.1). I have it configured to open new tabs by default instead of new windows.

I run my IRC client on the left monitor (:0.0) - this is usually where I end up clicking links to have them to open in Firefox. This actually works for me currently -- when I open a link, it opens in a new tab of the firefox window on :0.1. This behaviour is exactly how I want it -- I opened firefox on the centre monitor because I typically want to use firefox on the centre monitor. I never want to use it on the left monitor, that's for IRC.

Now, say I want to work on something. I put my work on the centre monitor, because it is largest. At the same time, I want to put up documentation or something on the right monitor (:0.2). At this point, I bring up my root menu and select "Firefox" on the right monitor, expecting a firefox window to open there. Currently, this will fail because it can't lock the profile, and I have to totally quit firefox on the centre monitor just so I can open a single page on the right monitor.

*** Bug 370236 has been marked as a duplicate of this bug. ***

*** Bug 393287 has been marked as a duplicate of this bug. ***

Could someone familiar with the code please take a look at how difficult it would be to rewrite the mozilla core to properly support multiple displays/screens? Maybe it's possible to have this as a google summer of code project.

It's probably not too difficult, just time consuming to go thru all the consumers of X/GDK Displays/Screens and make sure they are doing the right thing.

*** Bug 425092 has been marked as a duplicate of this bug. ***

*** Bug 425093 has been marked as a duplicate of this bug. ***

Nick Bowler's comment on 11/26/07 reflected exactly my perspective on this issue. I am writing an application that uses the Java Desktop class to open a URL for on-line help, and I'd like to be able to make the help come up on the same screen that our application is running. However, personally I prefer to keep my own browser on a single screen as Nick described.

There is already a preference setting for opening new links in new-window/new-tab/same-window. Perhaps the new-window option could obey the screen number of the screen on which the command line was invoked, but the other options could use the existing window. The OpenURL command sent by XRemoteClient would simply have to provide the screen number for optional use by the target process.

I haven't seen Firefox's Xlib code, but the API makes it easy to open windows on specific screens (without passing screen numbers very far around the code).

Are the fixes suited for trying in firefox3?

(In reply to comment #49)
> Are the fixes suited for trying in firefox3?

The patch should still apply. If not, throw me an email and I'll send you a new patch.

(In reply to comment #50)
> (In reply to comment #49)
> > Are the fixes suited for trying in firefox3?
>
> The patch should still apply. If not, throw me an email and I'll send you a new
> patch.
>

The files XRemoteClient are accurate in Fx2, but cant find them in Fx3. The bugfixes should be updated.

The files are still listed here: http://hg.mozilla.org/index.cgi/mozilla-central/file/dfb267af6f44/widget/src/xremoteclient/ (of course assuming that mozilla-central is the official fx repo. I'm using the client.mk makefile myself).

If there are/were fixes,... why aren't the applied to the vanilla sources?

(In reply to comment #53)
> If there are/were fixes,... why aren't the applied to the vanilla sources?

See comment #37

*** Bug 495209 has been marked as a duplicate of this bug. ***

Using Windows 7 x64 build 7100 (Release Candidate) running 32-bit Firefox 3.0.10, this problem does NOT exist. Firefox is working fine on dual-monitors. This problem existed for me in Vista in 3.0.9 however. I'm not sure if something changed in Win7 but it's fine now. In case you need my useragent for version info:

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)

(In reply to comment #56)
> Using Windows 7 x64 build 7100 (Release Candidate)

This bug is for Linux.

Jesper: My mistake - disregard my previous comment. Though strangely it did happen in 3.0.9 on Vista, however.

Still a bug in 3.5 beta 4

Ubuntu Bug:
https://bugs.launchpad.net/bugs/78538

Still a problem on Firefox 3.5 Final.

Would it be possible to get this fixed for 3.6?

Still a bug in Firefox 4! Oh, common

Argh! It's almost enough to make me learn C++!

I see this issue as well on Ubuntu in dual head mode. (I don't use nvidia's twinview since it won't allow separate LUTs for each monitor.)
Since multi-headed X is a standard Unix feature it would be nice if Firefox handled it correctly. (Ubuntu just now discarded an automatic bug report since Firefox refused to fire up on the first display -I already had FF running on the second display.)

Still a problem in Firefox 6.0.2

...And in Firefox 11.0

same problem in firefox 21.0a2 (2013-03-29).
Fix this please! same problem in thunderbrd maybe is a problem of xulrunner?

The problem is always present even in firefox 26.
I hate this bug -.-', it's impossibiel for me use Firefox in a multi indipendent monitor configuration -.-'

The funny thing it that it's apparently easy to do... applications like GIMP just happily open windows on different X screens...

Any news for this very old bug??

It still persists after all these years :)

I would still like it to be fixed but sadly I have learnt to live without it using different profiles. It's a shame actually.

Yes, Firefox remains for me to be a back-up browser.

I have a pretty hacky workaround for this. It seems to be working fine initially, but I'm guessing this will break something eventually. BACK UP YOUR PROFILE BEFORE TRYING THIS

cd ~/.mozilla/firefox
mkdir screen1
mkdir screen2

# for bash
shopt -s dotglob

# for zsh
setopt GLOB_DOTS

cd screen1
ln -s ../<YOUR PROFILE>/* .
rm .parentlock

cd ../screen2
ln -s ../<YOUR PROFILE>/* .
rm .parentlock

From a terminal on screen 1...
firefox -P screen1 -new-instance

From a terminal on screen 2...
firefox -P screen2 -new-instance

Again, USE WITH CAUTION AND MAKE BACKUPS FIRST

Oops, forgot to mention you have to add the fake profiles to your profile.ini as well like so:

[Profile1]
Name=screen1
IsRelative=1
Path=screen1
Default=0

[Profile2]
Name=screen2
IsRelative=1
Path=screen2
Default=0

Interesting solution but it's works without problem with the database and the cache of the profile?

Daniele,

Databases are what I'm most worried about since ff probably thinks it has an exclusive lock on them. For simple browsing everything seems to be working as expected.

And I'm not familiar with the profile being cached, can you elaborate?

The profile folder have the cache of the pages.
My doubt is only the conflict with the cache, for the databases double connections can create some problems?

Ah, I see.

For anything transient like that you can just remove the symlink from the "fake" profiles and ff should recreate them, much like I already do for .parentlock.

The databases "shouldn't" be a problem in theory, as long as you don't trigger any write collisions. But in practice, a collision will almost definitely happen eventually. It is a risk which is why I don't purport this to be a real solution.

Maybe a solution is a bash script that do a backup before the execution of firefox.

Yeah this could easily be rolled into a script that

1) backs up the real profile
2) makes the fake profile
3) adds it to profile.ini
4) starts a new ff instance using the new fake profile

Its still not a "real" solution though, and its currently beyond my personal needs.

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.