319965 - Dual-monitors, FF opens in one or the other, not both. [linux]

Status: RESOLVED INCOMPLETE

Description

[Jeff]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) Gecko/20050920 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) Gecko/20050920 Firefox/1.0.7

I have dual monitors, not xinerama or twinview but separate X screens :0.0 and :0.1.
If I open a firefox instance on one monitor, I can never start another instance on the other monitor...they accumulate on the first monitor.
Even if I do:

$ DISPLAY=:0.0 firefox
$ DISPLAY=:0.1 firefox

FF still only opens in :0.0. Of course this can be reversed...
Thanks!


Reproducible: Always

Steps to Reproduce:
1.open firefox on DISPLAY=:0.0
2.try to open another firefox on DISPLAY=:0.1
3.Pray to the gods you get a FF instance on both screens

Actual Results:  
FF instances always open on the initial screen used.

Expected Results:  
I would expect a FF instance on each screen.

Comment 1

[José Jeria]

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

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

Comment 2

[Jeff]

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.

Comment 3

[zug_treno]

Duplicate of/related to bug 285954?

Comment 4

[Kyle K.]

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).

Comment 5

[Jason R Briggs]

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.

Comment 6

[Mark]

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.

Comment 7

[Jeff]

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.

Comment 8

[Alexander Sack]

ok ... confirming.

Comment 10

[guanxi]

Comment #6 is bug 264030

Comment 11

[Jeff]

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

Comment 12

[David Sveningsson]

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

Comment 13

[Tomas Carnecky]

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

Comment 14

[Tomas Carnecky]

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.

Comment 15

[Jonathan Watt [:jwatt] (needinfo? me)]

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.

Comment 16

[Tomas Carnecky]

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?

Comment 17

[Tomas Carnecky]

Created attachment 287156 [details] [diff] [review]
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 18

[Reed Loden [:reed] (use needinfo?)]

Comment on attachment 287156 [details] [diff] [review]
Fix XRemoteClient to support multiple screens

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

Comment 19

[Reed Loden [:reed] (use needinfo?)]

Requesting wanted1.9.

Comment 20

[Reed Loden [:reed] (use needinfo?)]

Comment on attachment 287156 [details] [diff] [review]
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.

Comment 21

[Alexander Sack]

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

Comment 22

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 287156 [details] [diff] [review]
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.

Comment 23

[Tomas Carnecky]

(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).

Comment 24

[Christopher Aillon (sabbatical, not receiving bugmail)]

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.

Comment 25

[Tomas Carnecky]

(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?

Comment 29

[Benjamin Smedberg]

Comment on attachment 287156 [details] [diff] [review]
Fix XRemoteClient to support multiple screens

please request sr once asac or caillon give r+

Comment 30

[Tomas Carnecky]

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.

Comment 31

[Reed Loden [:reed] (use needinfo?)]

(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. :)

Comment 32

[Tomas Carnecky]

Created attachment 290194 [details] [diff] [review]
 Fix XRemoteClient to support multiple screens (try 2)

Fixed the issue that is outlined in comment #22.

Comment 33

[Christopher Aillon (sabbatical, not receiving bugmail)]

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?

Comment 34

[Tomas Carnecky]

(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.

Comment 35

[David Sveningsson]

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)?

Comment 36

[Tomas Carnecky]

(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?

Comment 37

[Christopher Aillon (sabbatical, not receiving bugmail)]

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.

Comment 38

[Tomas Carnecky]

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!

Comment 39

[David Sveningsson]

(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)

Comment 40

[Jeff]

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.

Comment 41

[Nick Bowler]

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.

Comment 44

[Tomas Carnecky]

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.

Comment 45

[Christopher Aillon (sabbatical, not receiving bugmail)]

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.

Comment 48

[Eric Stadtherr]

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).

Comment 49

[Jesper Hansen]

Are the fixes suited for trying in firefox3?

Comment 50

[Tomas Carnecky]

(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.

Comment 51

[Jesper Hansen]

(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.

Comment 52

[Tomas Carnecky]

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).

Comment 53

[Christoph Anton Mitterer]

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

Comment 54

[Tomas Carnecky]

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

See comment #37

Comment 56

[Garret Smith]

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)

Comment 57

[Jesper Hansen]

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

This bug is for Linux.

Comment 58

[Garret Smith]

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

Comment 59

[Sergio Pascual]

Still a bug in 3.5 beta 4

Comment 60

[Micah Gersten]

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?

Comment 61

[Sergio Pascual]

Still a bug in Firefox 4! Oh, common

Comment 62

[Jeff]

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

Comment 63

[Patrik Floding]

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.)

Comment 64

[Idetuxs]

Still a problem in Firefox 6.0.2

Comment 65

[emerson]

...And in Firefox 11.0

Comment 66

[Daniele "Mte90" Scasciafratte]

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

Comment 67

[Daniele "Mte90" Scasciafratte]

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 -.-'

Comment 68

[Christoph Anton Mitterer]

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

Comment 69

[Daniele "Mte90" Scasciafratte]

Any news for this very old bug??

Comment 70

[Jeff]

It still persists after all these years :)

Comment 71

[David Sveningsson]

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.

Comment 72

[Launchpad]

keepitsimpleengr added the following comment to Launchpad bug report 78538:

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

-- 
http://launchpad.net/bugs/78538

Comment 73

[Alex Shafer]

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

Comment 74

[Alex Shafer]

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

Comment 75

[Daniele "Mte90" Scasciafratte]

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

Comment 76

[Alex Shafer]

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?

Comment 77

[Daniele "Mte90" Scasciafratte]

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?

Comment 78

[Alex Shafer]

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.

Comment 79

[Daniele "Mte90" Scasciafratte]

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

Comment 80

[Alex Shafer]

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.

Comment 81

[Benjamin Smedberg]

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.