User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 When using two monitors Firefox always opens in the left (main) monitor. It never remembers the last location (which is always the right monitor). It never opens in the right (secondary) monitor. This does not happen when only using one monitor ;-). Reproducible: Always Steps to Reproduce: 1. Using two monitors. Open firefox. 2. Move browser to right (secondary) monitor. 3. Close Firefox. 4. Open Firefox. It opens in left (main) monitor. Expected Results: Firefox should remember the last closed position and reopen there, even if it is in the secondary monitor.
Note: In the above two duped bugs, bug 333966 and bug 336595, the reports said the window had to be maximized in the secondary monitor for the error to occur.
11 years ago
Duplicate of this bug: 426385
Bug Bug 474331 was marked a duplicate of this bug, but I'm not sure that it is. I'm describing remembering virtual desktops, whereas this bug is discussing remembering different monitors. Here is my original bug description: When Firefox restarts, all browser windows appear on the current desktop (or space on the Mac). Firefox remembers what tabs it has open, which mostly restores the previous state of the browser. But if you have browser windows open on multiple virtual desktops, you currently have to manually figure out which one went where and place them back where they were before. It would be amazingly helpful if Firefox remembered which virtual desktop or space each window was in and opened those windows on the correct desktop, in the correct position.
I have got the problem with firefox and thunderbird, so this might be a core problem. Should/Could this be marked here somehow?
Component: General → General
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
As noted in bug 465240 comment 4, you should resize the window a little bit. That seems to save the current monitor in localstore.rdf, not the moving of the window. Note that maximizing a window isn't the same as resizing it (see bug 465240)
Here is also a good description of this bug: http://forums.whirlpool.net.au/forum-replies-archive.cfm/847096.html Quote from ghulp: -------------------------------------------------------------------------------- The latest versions of Firefox only remember which monitor they are on if you close Firefox while it is not maximised. So procedure to get firefox to open maximised on the monitor of your choice in dual monitor setup: 1) Un-maximise Firefox window 2) Position un-maximised window on monitor of you choice 3) Close Firefox window 4) Reopen Firefox window 5) Maximise Firefox window 6) Close Firefox window Now Firefox will open maximised on the screen you chose. ----------------------------------------------------------------------------- When will this annoying bug fixed?
I have the opposite problem: Firefox always opens on my right-most (primary) monitor, even though I always close it (maximized) on my secondary (left-most) monitor. Multi-monitor application bugs are one of my pet peeves, partially because Windows has two functions (GetWindowPlacement/SetWindowPlacement) that will do it correctly for you (and handles all the corner cases). Don't try to reinvent the wheel, you'll most likely screw it up. If you're not using GetWindowPlacement/SetWindowPlacement (which apparently Firefox isn't), then you've probably (in this case, definitely) overlooked something.
Component: General → Widget: Win32
QA Contact: general → win32
Summary: Using dual monitors, Firefox always opens in left monitor, does not remember right monitor location. → Using dual monitors, Firefox/Thunderbird always opens in wrong monitor, does not remember correct monitor location when maximized
Whiteboard: [gs] → [gs][duptome]
Created attachment 543486 [details] [diff] [review] Patch v1 (WIP) I think this patch fixes the problem on OS X. I'm not sure whether it breaks other platforms though -- it's undoing the changes made in rev 1.23, which points to bug 30116, which was a bug filed against windows 98. Will be checking the effect of these changes on other platforms next week.
Sorry, I'm no longer working on this bug. I don't have access to the necessary platforms to test if the patch works.
(In reply to Jez Ng [:int3] from comment #74) > Sorry, I'm no longer working on this bug. I don't have access to the > necessary platforms to test if the patch works. VirtualBox allows you to emulate several monitors even if running on a single monitor system. Have you considered this as a potential test platform?
Because this bug also appears on Mac OS X and on Linux (see 730611), selected component must be wrong.
Component: Widget: Win32 → Widget
QA Contact: win32 → general
(In reply to guzzy from comment #90) > doh. Perhaps people can post which platforms have been tested to work with > the patch, so that people with the remaining platforms can test and post > results. I tested it on OS X. I suspect that the changes in nsCocoaWindow.mm should be similarly applied to the window objects for other platforms as well, but as I couldn't test on them I didn't actually make the changes. There's also the issue of possible regressions -- IIRC the changes in nsXULWindow.cpp are reverting changes made way back in the past for WindowsCE (!). But I think if no regressions show up on the major modern platforms then it should be fine. If anyone wants to step up to port the patch & test on other platforms I'd be grateful. (In reply to joel from comment #91) > Would someone tell me how to install the patch on OSX Lion 10.7.3? Download it and do `hg qimport`. If you haven't built Firefox yet, read https://developer.mozilla.org/en/Introduction and ask questions in #introduction. Thanks!
(In reply to joel from comment #106) > I don't think it is on anyone's radar as this new high speed progression of > Firefox and Thunderbird is all that is on the mind of the developers. As > You can see no one has picked this up after all this time. Many bugs related to Fx 12 (bug 750055, bug 750537, bug 750999, and bug 754255 - see also comment 79 and above) have been wrongly dupe to this bug and should have been dupe to bug 752149 (was on Paul O'Shannessy's radar), which is fixed from Fx 14.
workaround that I have been using for a decade : comment 37
This was fixed until the latest update to 16.0, now it's back again, even after maximimsing, minimising, relaunching, deleting then re-adding tabs. My OS Mac Lion is 10.7.5 and I have two 30" Apple Cinema Display monitors.
I am not versed in cpp or GTK or anything like that, but I just noticed: There are a bunch of gdk_window_get_screen() and friends in mozilla-central/widget/gtk2, but in the whole directory, not a single file calls gtk_window_set_screen(). So, it looks to me as if someone forgot to add this line, and maybe someone should check the source and add the command whereever it would be required. As I said, I have never coded cpp, so I can't do it myself, but I hope this info helps. For the record: Firefox 16.0.1 on Linux Mint, two screens, same problem. Also really annoying as it even overrides default workspace settings on the window manager "awesome", so you can't even force it to a specific tab with it.
This becomes more critical with Retina displays due to font display problems when switching between Retina displays and external monitors described in bug 764083. Comment #37 does help (resizing to less than maximum size on the monitor I want, quit, then start again).
Copied steps to reproduce and workaround from duplicated bug 704803. Maybe an adapted workaround works also on non Windows platforms. Problem occurs (steps to reproduce): - Open Firefox maximized(1st monitor) - Press WindowsKey+Shift+Right to move Firefox to 2nd monitor - Close Firefox - Reopen it --> opens on 1st monitor Problem does not occur (workaround): - Open Firefox maximized (1st monitor) - Press the "Restore Down" icon upper right (so Firefox is not maximized anymore) - Press WindowsKey+Shift+Right to move Firefox to 2nd monitor - Maximize Firefox - Close Firefox - Reopen it --> opens on *SECOND* monitor
tobias: That workaround seems to only work for Windows, on my Linux machine, it will still open on the wrong screen every single time.
Problem still occurs for me as well, It got so annoying that I hacked together a quick vbscript to modify the localstore.rdf and shift the window back to the main screen (I always end up with the window stuck on the second screen). All you'd need to do is change the pixel position that it is writing from 2,2 (the lines with screenX and screenY) to whatever you want it to be and change the sizemode to what you want. I'm going to attempt to attach it to this ticket. It only works for Windows 7 currently, but would be fairly trivial to make work on XP. If you've got the same problem as me, then you can just run the vbs file and it will sort the issue temporarily.
Created attachment 750788 [details] Vbscript to reset the window position on Windows 7 No idea if I'm attaching this correctly
I have a dual boot system (Win7 Home & Fedora 18/Gnome 3.4) and I don't have a problem with Win7 but for several versions of Fedora, FF has always opened in the primary screen and I have to move it to the secondary screen were I prefer to use it. So just wanted to put my vote in to get some attention to correcting this annoyance. DM
#144: As it has been said multiple times in the comments, this does not always work, and does not work under Linux at all.
"There is a quick work around for that. Open firefox, un-maximized it, move it to the other screen, close it. It will be on that screen next time you open it. You can now maximize it without any problem." This doesn't do anything at all. Still have the problem with OS X 10.8.4, FF 23.0.1 running on an early 2008 Mac Pro 3,1 I deleted the preferences but still no joy.
The workaround is for the Windows issue. Issues in Linux/OS X may not have the same underlying cause.
Not the case when restarting after updating, it will always open in the wrong one.
Hi, sorry this bug hasn't found an owner so far. Since it looks like it'll need separate platform-specific fixes on Linux, Windows, and Mac OS X, I suggest the following to help to get things moving finally: 1) File three new bugs, one for Widget:Gtk (linux), one for Widget:Cocoa (mac), and for under Windget:Win32 (windows). Mark each of them as "blocking" this original bug. 2) Copy Jez's patch (attachment 543486 [details] [diff] [review]) to the Widget:Cocoa bug and update it if necessary. 3) Copy the information in comment 123 to the Widget:Gtk bug. Then we can use this bug as a meta/tracking bug, while actual work takes place in the three platform-specific bugs. The platform-specific bugs are more likely to be seen by people working or searching in those separate components, and will be easier to read since they will (I hope!) remain free of advocacy comments. If people who want to help test the bug on each platform would like to start filing these bugs now, that'd be great; otherwise I will do it in the next few days. I'll also try to locate owners for each of the platform specific bugs.
Don't forget comment 51 for the Widget:Win32 bug! Storing the window position for windows and it's not in a WINDOWPLACEMENT struct (or analog thereof)? shameful!
Thank you Matt, i hope that this will help. But how do we get the votes from this ticket to its children? I unterstood from earlier comments that only with votes there is a chance that someone starts working on it.
Votes are almost completely ignored, this is not a democracy. They might be used to decide what is a popular bug or not, but they don't directly influence the decision process. But that's all off-topic.
So what is voting for then?
50 cents: as it works on windows, and remebering where you are on screen is a build-in feature, it's clearly a bug. O= How you find out where your windows are : xwininfo First one is NOT maximised : xwininfo: Please select the window about which you would like information by clicking the mouse in that window. xwininfo: Window id: 0x12000a0 "264030 – Using dual monitors, Firefox/Thunderbird always opens in wrong monitor, does not remember correct monitor location when maximized - Mozilla Firefox" Absolute upper-left X: 1504 Absolute upper-left Y: 118 Relative upper-left X: 10 Relative upper-left Y: 42 Width: 1144 Height: 803 Depth: 24 Visual: 0x21 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +1504+118 -72+118 -72-103 +1504-103 -geometry 1144x803-62+76 This one IS maximised : xwininfo: Please select the window about which you would like information by clicking the mouse in that window. xwininfo: Window id: 0x12000a0 "264030 – Using dual monitors, Firefox/Thunderbird always opens in wrong monitor, does not remember correct monitor location when maximized - Mozilla Firefox" Absolute upper-left X: 1440 Absolute upper-left Y: 34 Relative upper-left X: 0 Relative upper-left Y: 34 Width: 1280 Height: 990 Depth: 24 Visual: 0x21 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +1440+34 -0+34 -0-0 +1440-0 -geometry 1280x990-0+0 Possible solution: AS thunderbird and firefox with x11 decide the position on the fact where the mousepointer is at startup, a fix could be to "overwrite" that information on purpose.
O== Workaround: HOW TO FIX for Fedora & Gnome 1) install xdotool sudo yum install xdotool 2) edit the startparameter of your desktop/menuentry to: bash -c "xdotool mousemove 1540 134;firefox %u" where 1540 134 are the Left-Top Coordinates inside your secondary screen. You can move the mouse anywhere you like inside the screen. I suggest to use resonable positions, so that you don't need to search for your mousepointer. For this example my primary screen is 1440x900, so i choosed 1540 as it's 100px away from the left side of the sccreen. If you need a graphical hint, check this out: http://marius.bloggt-in-braunschweig.de/2014/06/01/thunderbird-und-firesfox-auf-dem-zweiten-screen-oeffnen/
Not anymore repro for me on FF branch 31, Win7 x64 (same environment when I saw it).
This just started happening for me with Thunderbird 31.6 on Windows 7.
(In reply to Martin Giger from comment #171) > This just started happening for me with Thunderbird 31.6 on Windows 7. Could you open a new bug report for that in the "Thunderbird" product, please? Make sure to mention this bug in the new report, and the fact that the behavior has started occurring again in a new version. Thanks!
(In reply to Matt Brubeck (:mbrubeck) from comment #172) > (In reply to Martin Giger from comment #171) > > This just started happening for me with Thunderbird 31.6 on Windows 7. > > Could you open a new bug report for that in the "Thunderbird" product, > please? Make sure to mention this bug in the new report, and the fact that > the behavior has started occurring again in a new version. Thanks! I'll wait another week, since I can't reproduce it on windows anymore, but it now happens on Linux, which was a fresh install.
just checked: Linux Thunderbird => does open where the mouse pointer is Linux Firefox => does open where the mouse pointer is FireFox: 37.0.1-1 FC20 Thunderbird: 31.5.0-1 FC20
BTW: there are a few bugs open with this dual monitors problem, opening a new one won't help IMHO.
Whiteboard: [gs][duptome][Australis:P?] → [gs][duptome][Australis:P?][tpi:-]
Problem still exists 13 years later. My setup: * Ubuntu Linux 16.04 * 3 monitors * Firefox 52.0 (64-bit)
This bug is already fixed on Windows. For other platforms, someone has to implement nsIWidget::GetRestoredBounds() on the platform. (I can't because I have only Windows box.)
With FF 52.0.1 on Windows 7 64 Bit the bug seems to be fixed.
in Windows it was fixed long ago. It's a *nix problem as stated in #179
Facing this problem again and again, 2 Monitors Thunderbird 52.1.1 (64-bit) Linux Mint 18.1 Serena
On windows this is fixed. we have individual bugs for osx and linux on file.
Status: NEW → RESOLVED
Last Resolved: 9 months ago
Resolution: --- → WORKSFORME
This always happens when using remote desktop. If you minimize Firefox or Thunderbird windows - bringing them to the foreground is mission impossible.
(In reply to Dobri from comment #184) > This always happens when using remote desktop. > If you minimize Firefox or Thunderbird windows - bringing them to the > foreground is mission impossible. Also, the same thing happens with Telegram, so something in common?
It's not a "nix problem. Note that Chrome and Opera on *nix has no such issue. Only FF does.
You need to log in before you can comment on or make changes to this bug.