User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b11) Gecko/20100101 Firefox/4.0b11 Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b11) Gecko/20100101 Firefox/4.0b11 When I plug in an external monitor to my MacBook and put Firefox to the "slave screen", I can't open certain windows (tried download window and "show source code of website"). After moving Firefox to the main (or "master") monitor, there is no problem. Doesn't seem to be a problem on other platforms (tried on Ubuntu Linux). Reproducible: Always Steps to Reproduce: 1. Start Mac OS X (Snow Leopard) and plug in a second screen 2. Move Firefox to the slave screen (that's the screen without the Apple menu) 3. Open the download window of Firefox (CMD+J) Actual Results: Window doesn't appear. Expected Results: Window appears. Very annoying issue because, for example, at every download the progress bar is missing.
I am having a similar issue trying to open new browser windows. When a browser window is active in the slave screen and I try to open a new window (Either by selecting File - New Window in the Apple menu, or by right clicking to open something in a new window), the window does not open. It will show up in the list of Windows in the Apple menu, but it can't be selected. If I close FF and restore the session, the windows still don't appear (but still show up in the Apple menu). If I move the active window into the main screen, I can open a new window as expected (using either of the methods mentioned above).
I've got the same thing with FF4 for Mac on OSX 10.6.6. If the main Firefox window is on the slave screen then I can't create a new Firefox window using Command-N. If I drag the Firefox window to the master screen then it behaves perfectly fine. This happens always.
I second Andy's report. FF4 on Mac OSX 10.6.6 command-j (download window) or command-n (new window) yields either no visible window or windows with very odd geometry, e.g. 1px wide. See example screenshot.
I'm seeing this too. I suspect bugs: 642870, 653855 are duplicates. Probably many others. If the mozilla window with FOCUS is on the main screen (the one with the Apple menu), then Open New Window works -- both Cmd-N and from the menu. If the mozilla window with FOCUS is on the secondary screen, it does not open a new window -- both Cmd-N and menu will not work. Model Name: iMac Model Identifier: iMac8,1 Processor Name: Intel Core 2 Duo Processor Speed: 3.06 GHz Number Of Processors: 1 Total Number Of Cores: 2 System Version: Mac OS X 10.6.7 (10J869) Kernel Version: Darwin 10.7.0
Can everyone please try if that only happens when the secondary screen gets plugged in after Firefox has been started? What happens if Firefox gets started afterward? I have a secondary screen at home which is always connected and haven't seen this problem.
My secondary screen is always connected, and I see the problem as reported.
My monitors are also always connected, and I see the problem as reported.
This bug is present in the Nightly build as of 4/30/2011. 100% reproducible 1) Multiple monitor system with Firefox open on the main [menu bar] monitor 2) Open a new browser window 3) Drag the new browser window to the 2nd, 3rd, etc monitor 4) You now have the bug for any function that opens a new window as long as the active browser window is not on the main monitor. 4a. Select Tools::Downloads the Downloads window DOES NOT open but it is listed in the Windows menu 4b. Select Tools::Error Console the Error Console window DOES NOT open but it is listed in the Windows menu 4c. Select File::New Window the New Browser window DOES NOT open but it is listed in the Windows menu 4d. On the new Browser Window created in step 2-3 enter a search string example "Intel x5650" in the Google search field and press enter The Google search results page for "Intel x5650" is displayed. 1. The 3rd item should be the Google Product page link with the title "Intel Xeon 2.66 GHz Processor" 2. Right click on the link and select the Contextual Menu Item "Open Link in a New Window" The new window DOES NOT open but "Intel Xeon 2.66 GHz Processor" is shown in the Window menu. 5) All of the windows that failed to open are inaccessible. You cannot select them from the Window menu.
This bug happens with a new profile. In the reproduction scenario listed above the rightmost monitor was the Main Monitor with the Menu Bar and the Dock. The additional 2nd or 3rd monitors were to the left of the main monitor in the Displays Preference Pane Arrangement dialog. If the active window on a monitor that is to the left of the main monitor then all open window or new window functions fail. Bugs 644733, 642870, 642443, 535782 are duplicates.
(In reply to comment #11) > If the active window on a monitor that is to the left of the main monitor > then all open window or new window functions fail. Does it also fail the other way around, means when those are placed at the right side?
To trigger this bug the Main Monitor MUST be the rightmost monitor If the menu bar is on a monitor that is not the rightmost monitor, then windows open as expected. If you then move the menu bar back to the rightmost monitor, the bug is back...
Ok, until I'm back and can try to reproduce the bug on my own, can you please tell us if that behavior is also visible in Firefox 3.6? If not, we have a regression and should try to find out the regression range. First step would be to check beta versions of Firefox 4 for the existence of the bug.
I just tested in v3.6 (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6) on OS X 10.6.7. The apple menu resides on my rightmost display. Opening a new window with command-n or downloads with command-j works with the main firefox window on either screen. It does not appear that the bug exists in this version.
The issue also existed from the first Firefox 4 beta release.
(In reply to comment #17) > The issue also existed from the first Firefox 4 beta release. Thanks for the info. Can you also please try the alpha releases we had for Firefox 4? Once we have a close range we can start to find the daily range. Alpha builds can be found here: ftp://ftp.mozilla.org/pub/firefox/releases/devpreview/
Works on all alpha builds (a1 through a5). Looks like it broke with first beta build.
Ledi, can you please open both a5 and b1 and check the dates of the builds under about:support? We would need those to start the bisecting between both builds. Thanks.
Also it would be nice if anyone of you who is experiencing this issue could attach the localstore.rdf file from the affecting profile to this bug. It could be that moving this file out of the profile could solve this issue. I cannot reproduce this bug on my dual-screen setup at home with the 2nd screen attached at the left.
Could not find a build date under a5. I found a build ID if you can track it to a date: browser.startup.homepage_override.buildID 20110413222027. Also, where can I download the beta version again?
Created attachment 532193 [details] localstore.rdf file from affected profile I attached the localstore.rdf from the affected version.
im having exactly the same issue it is most likely a duplicate of Bug #644733 this bug is caused by a change that was made on 2010-10-24 for fixing Bug #413277 The Problem is that when you arrange your Second Screen left and below your main Screen some values get negative and this is not handled correctly in widget/src/cocoa/nsCocoaWindow.mm FitRectToVisibleAreaForScreen(nsIntRect &aRect, NSScreen *screen) The last nightly build not having this issue is: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/10/2010-10-24-03-mozilla-central/ and the next one is having this issue: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/10/2010-10-25-03-mozilla-central/
i applied the patch that is attached to Bug #644733 and can confirm that it fixes this issue.
(In reply to comment #25) > im having exactly the same issue it is most likely a duplicate of Bug > #644733 this bug is caused by a change that was made on 2010-10-24 for > fixing Bug #413277 Yes, this definitely is. Can someone please dupe this into bug 644733?
Still present in FF 6.0 If somebody can point me down the right road, I'd love to commit a patch.
(In reply to Troy E. Lanes from comment #29) Troy, Please see 644733. There is a draft patch that needs some work. We've been stalled for review, but it finally got some review attention earlier this week and I was going to get back to it. Do you have more cycles to work on it and/or commit/review access? If so, by all means, please do so. Please move the discussion to 644733 however, thanks.