Firefox doesn't open new windows on secondary screen if main screen is on the right

RESOLVED DUPLICATE of bug 644733

Status

()

Firefox
Shell Integration
RESOLVED DUPLICATE of bug 644733
7 years ago
6 years ago

People

(Reporter: Pascal Grochol, Unassigned)

Tracking

4.0 Branch
x86_64
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [bugday-20110513])

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
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.

Comment 1

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

Comment 2

7 years ago
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.

Comment 3

7 years ago
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.

Comment 4

7 years ago
Created attachment 528089 [details]
screenshot of wonky newly opened window

Comment 5

7 years ago
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
Duplicate of this bug: 653855
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.

Comment 8

7 years ago
My secondary screen is always connected, and I see the problem as reported.

Comment 9

7 years ago
My monitors are also always connected, and I see the problem as reported.

Comment 10

7 years ago
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.

Comment 11

7 years ago
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?

Comment 13

7 years ago
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...
Duplicate of this bug: 642870
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.
Summary: Firefox doesn't open certain windows (e.g. download window) when using two screens → Firefox doesn't open new windows on secondary screen if main screen is on the right
Version: unspecified → 4.0 Branch

Comment 16

7 years ago
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.

Comment 17

7 years ago
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/

Comment 19

7 years ago
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.
Whiteboard: [bugday-20110513]

Comment 22

7 years ago
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?

Comment 23

7 years ago
Created attachment 532193 [details]
localstore.rdf file from affected profile

I attached the localstore.rdf from the affected version.
Duplicate of this bug: 656570

Comment 25

7 years ago
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/

Comment 26

7 years ago
i applied the patch that is attached to Bug #644733 and can confirm that it fixes this issue.

Comment 27

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

Updated

7 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 644733

Comment 29

6 years ago
Still present in FF 6.0  If somebody can point me down the right road, I'd love to commit a patch.

Comment 30

6 years ago
(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.
You need to log in before you can comment on or make changes to this bug.