Open Bug 1285200 Opened 8 years ago Updated 2 years ago

The second Firefox window appear on the wrong screen (new bug in branch 46)

Categories

(Core :: Widget: Win32, defect)

47 Branch
x86_64
Windows 7
defect

Tracking

()

UNCONFIRMED
Tracking Status
firefox49 --- wontfix
firefox50 --- wontfix
firefox51 --- wontfix
firefox52 --- fix-optional
firefox53 --- wontfix
firefox54 --- wontfix
firefox55 --- fix-optional
firefox56 --- fix-optional

People

(Reporter: elofu17, Unassigned, NeedInfo)

References

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0 Build ID: 20160623154057 Steps to reproduce: I start FF. (from quicklaunch, from an URL-shortcut on the desktop, etc on my Windows 7) Actual results: FF is opened on my secondary screen. Expected results: FF should have opened on my primary screen. I've run my laptop in dual-head for years, and FF has always (note 1) started on the correct screen. However, since about a month ago, FF always (note 2) open on the *wrong* screen. note 1: FF remember the window placement upon closure, so once in a while, FF accidentally start on my second screen if my last action was to close it *there*, before I shut down the computer. This is the correct behavior. It was my "fault" it started on the wrong screen and it is easily rectified by starting and closing FF on the primary screen so it remember that location. note 2: The only times it open up on the correct screen is when I manually do the manouver in note 1. Then FF will, temporarily, open on the primary screen. Normally in a period of 30 days, I might use the manouver 5 times. Today I have to use the manouver several times, every day. Tidious! My guess is that you have changed how the window placement is stored upon closure. I also guess that the problem manifest itself due to me alternating between booting the laptop in single-monitor mode (at home) and in dual-mode (at work). At home, with only one screen (the laptop screen), it becomes the primary screen. I start FF. It opens on the screen. I surf. Later I close FF. The window placement location is stored. The next day I go to work and connect my extra monitor and boot the laptop. Windows start up and I have dual-head. One detail that might be important here is that the external monitor (to the left) is my primary screen while the laptop screen is the secondary (to the right). I have extended my desktop to it. I start FF and expect it to appear on my primary screen, but it appears on the laptop screen. :-( It feels like that the new FF (branch 46? 47?) store *too much* information about the window placement upon closure. It feels like it remembers which physical screen it was using. Like: at home, in single-monitor mode, it remembers the placement and that it was using the laptop screen. So when I get to work, FF is started on the laptop screen even though this now my secondary screen, that should not be used unless I manually drag stuff over there. Can you please revert back to the way it used to be?
Keywords: multi-monitors
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
Could you test with Nightly, somes issues about multi-screen have been fixed to fix regression from bug 890156. https://nightly.mozilla.org/
Component: Untriaged → Widget: Win32
Flags: needinfo?(elofu17)
Keywords: multi-monitors
Product: Firefox → Core
Hi! Sure! I'll install it and test. I won't be back at work until monday though, so you have to wait a couple of days for my response. Have a nice weekend.
Yay! Nightly works fine! :-) FF windows that were closed and stored in single monitor mode are *not* opened on the secondary screen. Good.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Flags: needinfo?(elofu17)
Resolution: --- → DUPLICATE
Resolution: DUPLICATE → WORKSFORME
Hmmm. No. We cannot start celebrating yet. The latest Nightly still doesn't behave good. I start the laptop at home (no extra monitor). I surf. I close Nightly. I then start the laptop at work, in dual-head, with the Windows primary screen set to the external monitor (to the left of the laptop). 9 times out of 10, Nightly is started on the screen to the right (the laptop screen). :-( I haven't found a pattern for when things work correctly and when not. :-/ The first opened window, e.g. from my Quicklaunch icon, can be opened on the left screen as it should, and I go "Wheee, it's working". Then I start another window, again from the Quicklaunch icon. yepp, still opens on the left screen. good. Then I double click on an url shortcut on my desktop. The window appear on the right screen. :-( I double click on another url shortcut on my desktop --> right :-( I click on the Nightly icon in my Quicklaunch --> right :-( By closing all Nightly windows, starting a new one, drag it to the left screen and close it, many new windows are opened to the left, but not all and not always. So, the problem is not resolved. Many times every day I have to drag the window from the right screen to the left, no matter how I try to make Nightly store the correct position by closing it on the left screen.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Component: Widget: Win32 → Session Restore
Product: Core → Firefox
Version: 47 Branch → 49 Branch
Just an update. This annoying behaviour is still happening in Firefox 49.0.2. FF always start on the wrong screen, the laptop, not the big external screen. I constantly have to drag all my new FF windows from the laptop screen to my external screen. This is quite tedious. Please let me know if I can help debugging this.
Could you install the tool mozregression to narrow down a regression range(probably in 47or 46). http://mozilla.github.io/mozregression/ After the run, copy here the final pushlog from mozilla-inbound.
Component: Session Restore → Widget: Win32
Flags: needinfo?(elofu17)
Product: Firefox → Core
Loic, I tried the tool, but it is not suitable to test my case (since I need to reboot the computer and connect/disconnect an external screen between runs, to see where the FF window will be placed). Is there some manual way that I can find the regression instead? Like if I install and run an old version of Nightly from https://archive.mozilla.org/pub/firefox/nightly/2016/... If it turns out OK I skip forward a few days and try that build. *repeat* Is this a good approach? Is there some way for me to see a changelog of Nightly builds, so I don't install a nightly from a newer date but which contents has no new changes checked in, i.e. it is the same version?
Without testing anything at all, I found the following release information for the official Firefox software: On June 7, 2016 v47.0 was released. On July 7, 2016, I created this bugzilla ticket, and I wrote "since about a month ago, FF always open on the *wrong* screen". To me this indicates that the regression was on June 7, when I got FF v47.0. Please let me know how I can help debug this further.
My idea for a testing setup on your machine: 1) Create a new test profile (firefox.exe -P), e.g. "test" 2) Download each Nightly build as standalone (zip archive) and unzip the folder \firefox on \Desktop (e.g) 3) Make a copy of the current desktop shortcup of Firefox and edit its properties to modify the target path with the profile "test" and the nightly executable stored in /firefox: C:\Users\<User>\Desktop\firefox\firefox.exe -P "test" -no-remote So each time you click on this shortcut, the Nightly build is started with your test profile. When a different Nightly is downloaded, you just need to unzip and erase /firefox to test again quickly (in addition, as it's the same profile, your settings are stored). To download the Nightly builds, use the FTP of Mozilla and the repository mozilla-central for each day: http://ftp.mozilla.org/pub/firefox/nightly/2015/12/ Nightly 46 started in Dec. 2015, so you can start with the build from 2015-12-01: http://ftp.mozilla.org/pub/firefox/nightly/2015/12/2015-12-01-03-02-26-mozilla-central/firefox-45.0a1.en-US.win32.zip For the bad build boundary, you can start 3-4 months after Dec. 2015, say April 2016: http://ftp.mozilla.org/pub/firefox/nightly/2016/04/2016-04-05-03-02-14-mozilla-central/firefox-48.0a1.en-US.win32.zip To narrow down the regression range, use dichotomy, each time you divide the range by 2, to find the last good build and the first bad build. When you got the first bad build and the last good build, type about:buildconfig in the loaction bar of both builds and copy here the link from "Source" (and the date). With this info, we can have a pushlog.
Thanks! The idea with a static shortcut and simply replacing the firefox directory in between runs sounds good. I'll begin testing. Will let you know when I have any findings (might take several days).
Loic, FYI: If you suggest someting simillar in the future, remember to also instruct the user to start Nightly (with the test profile) and disable Auto update. Otherwise Nightly will be upgraded to the latest version... So, my findings: At home, booted with a single screen (the laptop): * I created a test profile using my current FF v49. * I installed an old Nightly v45.0. * Nightly auto-updated itself to v52. I deleted the firefox directory and unzipped the v45.0 zip again. * I started and closed Nightly using the test profile, to store the window position in single-head. * I also accidentally started and closed Nightly without specifying the test profile. At work, booted in dual-head (primary screen=external monitor (left), extended screen=laptop (right)): I start FF as I usually do (using the default profile), and it opens up on the correct screen!!! During the last months, it has always opened up on the extended screen. I guess that the accidental startup of the Nightly+default profile above stored v45.0 window placement values in my default profile instead of the bad v49.0 values. Just like in a previous comment of mine, this didn't last long. I just double-clicked an URL-shortcut on the desktop, and FF started on the expanded screen. :-/ Just like in that previous comment I can't find any pattern to when things go wrong. I double-clicked that same URL-shortcut 30 minutes later, and then the window appeared correctly on the primary screen. Anyhow... Running FF was not the real test here. So I start Nightly v45.0. It opens up on the correct screen. :-) good : 2015-12-01-03-02-26-mozilla-central/firefox-45.0a1.en-US.win32.zip At home, booted with a single screen (the laptop): * I replace the firefox dir with Nightly 2016-04-05-03-02-14-mozilla-central/firefox-48.0a1.en-US.win32.zip * I started and closed Nightly using the test profile, to store the window position in single-head. At work, booted in dual-head (primary screen=external monitor (left), extended screen=laptop (right)): I start Nightly and it appears on the correct screen. Doh. Since I don't know what action introduces the incorrect window placement, I can't force the problem. And without being able to force the problem, I can't find the point of regression. :-/ So... Back to square one. What should I do now?
Flags: needinfo?(elofu17)
Is the issue still reproducible with your current profile? Maybe there is an issue with this profile.
Loic, I created 5 different profiles, some "empty" and some a copy of my default profile, and ran some with Nightly and some With FF. No luck, things still work/fail as randomly as before. But then I happened to perform the test while switching virtual desktops, and that gave a different result. Sorry for not bringing up the fact that I'm using Dexpot+DexGrid on my Win7 to get a matrix of 4x3 virtual desktops. I haven't upgraded Dexpot, so it has to be FF that has changed its behavior around v47.0. I suspect that FF try to store the window location differently than v46, and that v47 get confused by my virtual desktops. Now, I think you're likely to go "Ah, well that's your problem then", and I totally understand that. This issue does not affect many FF users. I'm just wondering if you could take the time to investigate this further anyhow for me, to see if there's any way for people like me to get the old style back. Perhaps by adding an about:config option to store window location in "old style" or "legacy mode" something. :)
Loic, I found a way to reproduce the problem: Remove '-no-remote' from the shortcut. Close all firefox processes. Start Nightly on any Desktop and then start another Nightly on another desktop. The first appears on the current desktop you started it on. The second one however is placed on the right screen in "bad" versions of Nightly. In "good" versions, the window is placed on the current virtual desktop but adjusted to the upper right corner (just as if the window is trying to open up on the next Desktop or on the right screen, but is not allowed to). Now that I can force the problem I can try to find the point of regression... bad: 2016-04-05-03-02-14-mozilla-central/firefox-48.0a1.en-US.win32.zip (in the middle of the wrong screen) good: 2015-12-01-03-02-26-mozilla-central/firefox-45.0a1.en-US.win32.zip (upper right corner on current screen) bad: 2016-02-07-03-04-02-mozilla-central/firefox-47.0a1.en-US.win32.zip (placed waaay to the right on the wrong screen) bad: 2016-02-01-03-02-41-mozilla-central/firefox-47.0a1.en-US.win32.zip (placed waaay to the right on the wrong screen) bad: 2016-01-22-03-02-44-mozilla-central/firefox-46.0a1.en-US.win32.zip (placed waaay to the right on the wrong screen) good: 2016-01-05-03-02-11-mozilla-central/firefox-46.0a1.en-US.win32.zip (upper right corner on current screen) bad: 2016-01-14-03-02-46-mozilla-central/firefox-46.0a1.en-US.win32.zip (placed waaay to the right on the wrong screen) good: 2016-01-09-03-02-08-mozilla-central/firefox-46.0a1.en-US.win32.zip (upper right corner on current screen) good: 2016-01-12-03-02-27-mozilla-central/firefox-46.0a1.en-US.win32.zip (upper right corner on current screen) good: 2016-01-13-14-13-33-mozilla-central/firefox-46.0a1.en-US.win32.zip (upper right corner on current screen) Regression point found. Last good version: 2016-01-13-14-13-33-mozilla-central/firefox-46.0a1.en-US.win32.zip So, what I'm requestning is an about:config option for people like me, to force "legacy-2016-01-13-placement-position" of the second FF window (i.e. when a firefox process is already running).
about:buildconfig from Nightly 2016-01-13-14-13-33-mozilla-central/firefox-46.0a1.en-US.win32: Built from https://hg.mozilla.org/mozilla-central/rev/ad1f85f172b7302bef0fa9780df8e2b962780ac6 Build platform target i686-pc-mingw32 Build tools Compiler Version Compiler flags cl 1800 -TC -nologo -D_HAS_EXCEPTIONS=0 -W3 -Gy -arch:IA32 -FS -wd4244 -wd4267 -wd4819 -we4553 cl 1800 -TP -nologo -D_HAS_EXCEPTIONS=0 -W3 -Gy -arch:IA32 -FS -wd4251 -wd4244 -wd4267 -wd4345 -wd4351 -wd4800 -wd4819 -we4553 -GR- -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1 -Oi -Oy- Configure arguments --enable-crashreporter --enable-release --enable-update-channel=nightly --enable-update-packaging --enable-jemalloc --enable-require-all-d3dc-versions --with-google-api-keyfile=/c/builds/gapi.data --with-google-oauth-api-keyfile=/c/builds/google-oauth-api.key --with-mozilla-api-keyfile=/c/builds/mozilla-desktop-geoloc-api.key --enable-warnings-as-errors --enable-eme=adobe --enable-profiling --enable-verify-mar --with-branding=browser/branding/nightly
...and here's the about:buildconfig for the next Nightly, when things start to go bad (2016-01-14-03-02-46-mozilla-central/firefox-46.0a1.en-US.win32.zip) Built from https://hg.mozilla.org/mozilla-central/rev/6fa2ab99f52feb1b6ead5581b8f5d398546a55a5 Build platform target i686-pc-mingw32 Build tools Compiler Version Compiler flags cl 1800 -TC -nologo -D_HAS_EXCEPTIONS=0 -W3 -Gy -arch:IA32 -FS -wd4244 -wd4267 -wd4819 -we4553 cl 1800 -TP -nologo -D_HAS_EXCEPTIONS=0 -W3 -Gy -arch:IA32 -FS -wd4251 -wd4244 -wd4267 -wd4345 -wd4351 -wd4800 -wd4819 -we4553 -GR- -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1 -Oi -Oy- Configure arguments --enable-crashreporter --enable-release --enable-update-channel=nightly --enable-update-packaging --enable-jemalloc --enable-require-all-d3dc-versions --with-google-api-keyfile=/c/builds/gapi.data --with-google-oauth-api-keyfile=/c/builds/google-oauth-api.key --with-mozilla-api-keyfile=/c/builds/mozilla-desktop-geoloc-api.key --enable-warnings-as-errors --enable-eme=adobe --enable-profiling --enable-verify-mar --with-branding=browser/branding/nightly
Summary: Firefox window appear on wrong screen (new bug in branch 46 or 47) → The second Firefox window appear on the wrong screen (new bug in branch 46)
Loic, Correct. So, to recap: What I'm requestning is an about:config option where I can force new windows to be placed as they did before 2016-01-13. When a firefox process is already running, and I open a new window on another virtual desktop, I want it to open up on that particular desktop as it always did before 2016-01-13. I don't mind that the window is aligned to the upper left borders. The important part is that the window should not be opened to the other screen.
This behavior, where the second and any future FF windows are opened on the wrong monitor, is quite annoying on a daily basis. I really hope you will fix it, or leave an about:config option to override the new behavior.
Too late for a fix for 53, as we are in the last week of the 53 beta cycle.
Looking this over, seems like an edge case that's been around since 47. We could still take a patch but I don't think relman or regression triage need to track this.
Yes, this is an edge case that only affect users having multiple monitors and a Virtual Desktop Manager that expands the desktop. However, the regression is so annoying that a workaround should be created, I think. ...especially since things used to work pretty fine before FF 47. Recap: What I'm requestning is an about:config option to force new windows to be placed as they did before 2016-01-13, i.e. an option to force the use of the classic code instead of the new one in Bug 890156: I use a virtual desktop environment, consisting of 4x3 virtual desktops. I start a Firefox process somewhere, say on desktop #1 (upper left in the matrix). I navigate to a new virtual desktop, say desktop #2 to the right. I open up a new FF window. Naturally, I want this window to appear on this particular desktop, on the primary screen, not on the extra screen. Before 2016-01-13, it always did. ( On the screen, this second window is placed in the upper right corner, aligned to the borders, as if the window wanted to be opened to the right of the screen but was yanked back within the borders. I assume this is because of my virtual desktop coordinates. This placement is OK! The window is placed on the correct desktop and on the correct screen. I can now move to a new desktop an open yet another FF window, which is placed in the upper right corner of that desktop, and so on. Now I can easily switch between all three Firefoxes by navigating between the virtual desktops in the matrix. )
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.