Last Comment Bug 644733 - Can't open new windows if any windows are on a secondary monitor & primary and secondary are NOT TOP aligned (dual screen) [Mac]
: Can't open new windows if any windows are on a secondary monitor & primary an...
Status: VERIFIED FIXED
: regression
Product: Core
Classification: Components
Component: Widget: Cocoa (show other bugs)
: Trunk
: x86_64 Mac OS X
: -- major with 15 votes (vote)
: mozilla9
Assigned To: Benoit Girard (:BenWa)
:
Mentors:
: 609405 632606 632749 633901 645512 669659 680434 680719 688408 689863 693552 (view as bug list)
Depends on:
Blocks: 236647 413277 682753
  Show dependency treegraph
 
Reported: 2011-03-24 12:59 PDT by Devon Hubbard
Modified: 2011-11-29 10:44 PST (History)
47 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
affected
affected
affected
fixed


Attachments
Don't assume that screenBounds are positive! (998 bytes, patch)
2011-05-19 20:52 PDT, John Hawkinson
bgirard: review-
Details | Diff | Splinter Review
example display layout to reproduce bug #644733 (35.12 KB, image/gif)
2011-05-20 00:46 PDT, Devon Hubbard
no flags Details
patch (2.87 KB, patch)
2011-08-19 11:41 PDT, Benoit Girard (:BenWa)
smichaud: review+
Details | Diff | Splinter Review
patch (fix comment) (2.89 KB, patch)
2011-08-19 12:56 PDT, Benoit Girard (:BenWa)
christian: approval‑mozilla‑aurora-
Details | Diff | Splinter Review
644733_nightlyfix_example movie (3.28 MB, application/octet-stream)
2011-08-28 17:20 PDT, Devon Hubbard
no flags Details

Description Devon Hubbard 2011-03-24 12:59:30 PDT
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/533.20.25 (KHTML, like Gecko) Version/5.0.4 Safari/533.20.27
Build Identifier: Firefox/4.0

I'm not sure what triggers this behavior, but after upgrading from Firefox 3.6.16 (Mac) to Firefox 4.0 (Mac), I have run into runtime instances where I can't open any new browser windows.  The 'Window' menu lists numerous windows, but none are visible and selecting them from the Window menu results in no window appearing.  Similarly, selecting File>New Window or pressing CMD+N results in no window appearing although a new window name does appear in the Windows menu.

Reproducible: Always

Steps to Reproduce:
1. Launch Firefox 4.0
2. Surf various web sites, etc.
3. click on URLs in emails or other apps that result in opening those links in Firefox.
Actual Results:  
After about 10 mins of browsing sites, no new windows will appear.
Pressing CMD+N results in a new window name being added to the 'Window' menu, but not window visibly appearing on screen.
Resolving URLs from other apps results in a new window name appearing in the 'Window' Menu, , but not window visibly appearing on screen.

Expected Results:  
CMD+N should visibly display a new browser window.
Resolving URLs from other apps should result in a new browser window visibly appearing on the screen

Workaround:
Quit and relaunch FIrefox 4.0.  This works for awhile until whatever triggers this behavior occurs again.
Comment 1 Matthias Versen [:Matti] 2011-03-24 13:51:39 PDT
Please try http://support.mozilla.com/en-US/kb/Safe+Mode
Comment 2 Vlad [QA] 2011-04-08 01:11:12 PDT
Works for me on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.2a1pre) Gecko/20110407 Firefox/4.2a1pre

Also, could you see if the issue occurs if using Firefox in safe mode:
http://support.mozilla.com/kb/Safe+Mode

How about with a new, empty testing profile? (Don't install any addons into it)
http://support.mozilla.com/kb/Basic+Troubleshooting#w_8-make-a-new-profile
Comment 3 Devon Hubbard 2011-04-08 06:00:23 PDT
Yes, still occasionally occurs even with Firefox running in Safe Mode.
I'm also encountering the problem running on a clean (*) OS X install of an OS X 10.7 seed (11a419) even with Firefox running in Safe Mode.

*- clean as in not installed over the top of an existing 10.6.x install.
Comment 4 Devon Hubbard 2011-04-11 00:40:05 PDT
After numerous days playing around with this, the problem is reproducible with the following steps:

1) Download window is visible and downloading files.
2) In an external app, click on a URL, mailto link, etc. that would normally result in Firefox opening a new window for the URL to be resolved.

Result:
Nothing happens.  Notice that a new window name has appeared in the 'Window' Menu.  It's just not visible.

3) Close the Download window.   ( <<---* workaround * )
4) re-do items in step #2.

Result:
As expected, windows open for URLs external apps have requested be resolved by FireFox.

Notes:
I've been encountering this off n on again for several days and it too gather data across several launches across several days to know the Download window being open is the key.

This is reproducible with FireFox in Safe Mode or not; all extensions disabled or not.
This is reproducible on 10.6.7 and on 10.7 (11a419) on two different Macs.
Comment 5 Ed Morley [:emorley] 2011-04-11 03:13:04 PDT
Thanks for the updated steps.

I think the easiest way to move this forwards would be to find the regression range. Would you mind doing that? If so, the tool here should find the range for you within 20-30 mins:
http://harthur.github.com/mozregression/

Thanks again! :-)
Comment 6 Devon Hubbard 2011-04-12 19:28:22 PDT
I think I've found the root cause.  It's not the downloads window specifically that's causing this for me.  If *any* browser window is open on my secondary monitor (not the one with the menu bar), no other windows will open thereafter.

1) Setup a system with two monitors
2) Launch Firefox
3) Open a browser window, Downloads window, etc.
4) Drag that window to the secondary monitor (one that doesn't have the menu bar)
5) Press CMD+N

Result:
Nothing happens.  No new browser window opens.  A new window item has been added to the 'Window' menu though.

6) Click on a web link in another application that would normally open that URL in Firefox.

Result:
Nothing happens.  No browser window for the selected URL opens.  A new window item has been added to the 'Window' menu though.

7) Move the window that's on the secondary monitor back to the main screen and press CMD+N.

Result:
A new browser window opens now.  Didn't have to quit/relaunch Firefox to correct this.
Comment 7 Vlad [QA] 2011-04-21 06:57:13 PDT
Reporter, do you have anything new to add about this issue?
Comment 8 Devon Hubbard 2011-04-23 09:00:32 PDT
No.  Other than it is still reproducible using the steps noted above (comment #6)
Comment 9 Joe Walker [:jwalker] (needinfo me or ping on irc) 2011-04-26 04:41:39 PDT
I have this problem as well. If my browser window is on my "second monitor" then opening child windows is problematic.

More details:

- I have a MBP with an external monitor. The external monitor has the menubar and dock. So "second monitor" for me means my laptop display. Child windows work fine when the browser window is on the external display. If I unplug my external monitor, child windows work just fine.
- I get this effect with PageInfo, View Source, DOM Inspector, Error Console, Bookmarks, History
- I do not get this effect with Preferences, Clear Recent History, About

Maybe the distinction is a dialog/window thing?
Comment 10 [not reading bugmail] 2011-04-26 17:50:09 PDT
it sounds like your windows are there but on a display you cannot see.  For instance, I had been trying to run Firefox on a extended monitor and try opening a dialog or child windows and they will many times open on my primary display.
Comment 11 Devon Hubbard 2011-04-26 20:52:35 PDT
yes, correct.  as noted in the initial bug report, the windows are logically appearing in the Window menu.  They just don't appear visually.

Similar to Joe in comment #9, my menubar is on my external monitor and my laptop's main screen is the secondary monitor.
Comment 12 Joe Walker [:jwalker] (needinfo me or ping on irc) 2011-04-27 00:15:03 PDT
I did some digging into the "a display you cannot see" idea. I used a macosx tool to move windows around using the keyboard, and while I was able to select the windows for keyboard movement, they didn't report any size/location information. So I think the windows are incorrectly opened.

So current best repro steps:
- plug in an external monitor
- move your menu/dock to the external monitor
- move firefox to the laptop display
- open a child window, e.g. downloads/page info/view source

Expected behavior:
- the child window appears

Actual behavior:
- the window does not appear
Comment 13 Rob Campbell [:rc] (:robcee) 2011-04-27 04:47:55 PDT
check localstore.rdf, search for <RDF:Description RDF:about="chrome://browser/content/browser.xul#main-window" and take a look at the sizes and positions there. It's likely you have a default stored off-screen.
Comment 14 Joe Walker [:jwalker] (needinfo me or ping on irc) 2011-04-27 05:09:25 PDT
I don't think this is simply a stored window position problem:
- If I move FF to my external monitor, everything works fine
- If I have only my laptop display, everything works fine
- This happens for many child windows, but not those things that are xul:dialogs, only xul:windows

However this is what I do get:

  <RDF:Description RDF:about="chrome://browser/content/browser.xul#main-window"
                   sizemode="normal"
                   screenX="-1440"
                   screenY="1020"
                   height="900"
                   width="1200" />

Now my understanding is that screenX="-1440" is correct (0,0 is the top left of the menu bar) but that could well be what confuses things.
Comment 15 Joe Walker [:jwalker] (needinfo me or ping on irc) 2011-04-27 05:12:51 PDT
That is it: If I move my laptop to the RHS of my external monitor, it all works.

Devon, please could you confirm that:
- you have your laptop to the left of your external monitor
- if you move you laptop to the right, it works fine (no need to physically move it, just change the position in displays->preferences)
Comment 16 Joe Walker [:jwalker] (needinfo me or ping on irc) 2011-04-27 05:16:15 PDT
So current best repro steps:
- plug in an external monitor, configured to the *right* of your laptop.
- move your menu/dock to the external monitor
- move firefox to the laptop display
- open a child window, e.g. downloads/page info/view source

Expected behavior:
- the child window appears

Actual behavior:
- the window does not appear
Comment 17 Devon Hubbard 2011-04-27 11:03:39 PDT
re: comment #15
Yes, if I rearrange my monitors to where the main laptop display (without the menu bar) is on the right side of the main display (with the menu bar), then I can't reproduce this problem.
Comment 18 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-05-05 14:35:51 PDT
Devon, can you try using the following tool to find a regression range for this bug?

http://harthur.github.com/mozregression/
Comment 19 John Hawkinson 2011-05-19 14:34:06 PDT
Not sure what happened to Devon, but I see this bug reliably on several 3-headed macs running OSX 10.6.7 with FF 4 and FF4.0.1. Usually we grin and bear it, but today I hunted down this bugzilla bug.

Ran the mozregression. It gets:

Last good nightly: 2010-10-24 First bad nightly: 2010-10-25

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=094d838ed780&tochange=3ddfa411f716

The obvious candidate is
josh@mozilla.com
Sun Oct 24 18:38:48 2010 -0700	0fed77757e88	Scott Greenlay — Bug 413277: Restrict window resizing to the size of the current screen on Mac OS X. r=josh a=josh

Also, somewhat separately, I am not certain but I suspect the following bugs should should be duped into this one: 591176, 589969, and 591532.
Comment 20 John Hawkinson 2011-05-19 16:41:49 PDT
> The obvious candidate is ... 0fed77757e88	Scott Greenlay — Bug 413277

Confirmed. I'm not familiar with the mozilla build tree or mercurial, but I checked out a tree and ran "hg backout 0fed77757e88" and resolved the conflicts and the problem goes away.
Comment 21 Devon Hubbard 2011-05-19 19:41:28 PDT
I've run moznightly and can confirm the same overall regression results as you [John]...

2010-10-24 == good
2010-10-25 == bad

I'm unfortunately not familiar enough with the codebase and build environment to do a finer regression on the 18 checkins that occurred between those two nightlies to help zero in on the specific delta.
Comment 22 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-05-19 20:40:35 PDT
Thanks John and Devon for finding the regression range -- a 24 hour window is usually "good enough" for developers to isolate the issue.
Comment 23 John Hawkinson 2011-05-19 20:52:30 PDT
Created attachment 533878 [details] [diff] [review]
Don't assume that screenBounds are positive!

(In reply to comment #22)
> Thanks John and Devon for finding the regression range -- a 24 hour window
> is usually "good enough" for developers to isolate the issue.

Well, we can do a little better. Here's a patch. The problem is clear, the code that tries to clamp the window to fit within the current screen assumes that the current screen geometry is in positive numbers, and that's frequently untrue. (In my case, the center screen's upper-left corner is [0,0] and there is screen to the left and a screen to the right.)

That gives cases like this:
218       if (aRect.x - screenBounds.x + aRect.width > screenBounds.width) {
219         aRect.x += screenBounds.width - (aRect.x - screenBounds.x + aRect.w\
idth);

(gdb) printf "(%d)-(%d)+(%d)=(%d) > (%d)\n",aRect.x,screenBounds.x,aRect.width, aRect.x-screenBounds.x+aRect.width,screenBounds.width
Previous frame inner to this frame (gdb could not unwind past this frame)
(0)-(-1280)+(1)=(1281) > (1280)

I think my patch is not quite right, though. It ends up putting these windows on the center screen rather than the side screen (a VAST improvement over having no window at all!!), but I think I am a bit confused about what a GeckoRect is, since it seems that the screenBounds.y for my GeckoRect is a large positive number, even when the NSScreen data (CocoaRect) is a small positive number (because my left screen's bottom is positioned a little above the center screen's bottom):
(gdb) print screenBounds
$14 = {
  <mozilla::BaseRect<int,nsIntRect,nsIntPoint,nsIntSize,nsIntMargin>> = {
    x = -1280, 
    y = 811, 
    width = 1280, 
    height = 1024
  }, 
  members of nsIntRect: 
  static kMaxSizedIntRect = {
    <mozilla::BaseRect<int,nsIntRect,nsIntPoint,nsIntSize,nsIntMargin>> = {
      x = 0, 
      y = 0, 
      width = 2147483647, 
      height = 2147483647
    }, 
    members of nsIntRect: 
    static kMaxSizedIntRect = <same as static member of an already seen type>
  }
}
(gdb) print *screen
$15 = {
  <NSObject> = {
    isa = 0x7fff70602aa0
  }, 
  members of NSScreen: 
  _frame = {
    origin = {
      x = -1280, 
      y = 85
    }, 
    size = {
      width = 1280, 
      height = 1024
    }
  }, 
  _depth = 0, 
  _screenNumber = 722486216, 
  _auxiliaryStorage = 0x106c3f660
}

At this point, I have a build environment and am happy to test other patches if desired.
Comment 24 Devon Hubbard 2011-05-20 00:46:52 PDT
Created attachment 533901 [details]
example display layout to reproduce bug #644733

Nice debugging John.  The trigger is definitely a monitor layout where the main display (the one with the menu bar) is higher than a monitor to the left of the main display *and* the only window currently open is on the left side monitor.

See attached example problematic layout and workarounds.
Comment 25 Henrik Skupin (:whimboo) 2011-05-24 01:51:31 PDT
See also bug 632606 which is probably a dupe of this one now.
Comment 26 Josh Aas 2011-05-26 14:18:32 PDT
*** Bug 632606 has been marked as a duplicate of this bug. ***
Comment 27 John Hawkinson 2011-06-17 19:26:19 PDT
OK, how do we make progress here? I was hoping someone familiar with this code would pick it up, but that has not happened. Would it be helpful for me to take the time to move the patch from not-quite-right to fully-correct, or is that not what is blocking a fix being committed? (not-quite-right is still much much better than the current state).
Comment 28 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-06-17 22:23:38 PDT
(In reply to comment #27)
> OK, how do we make progress here?

There is a patch in Josh's review queue (he is one of Mozilla developers most familiar with Mac).
Comment 29 Steven 2011-07-13 09:32:04 PDT
I have 2 monitors on my iMac. The left one is "lower" than the right. If I open FF on the 2nd monitor and then try to open any other window, the secondary windows will not open. If I open FF on the primary monitor, secondary windows will open, regardless of whether I've kept FF on the primary monitor or moved it to the secondary.

This is the most ridiculous bug I've ever seen.
Comment 30 Chris Lawson (gone) 2011-07-13 10:08:27 PDT
Steven, please re-familiarize yourself with

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

and re-read comment 27/28 before commenting further.

Josh, how far down your current queue is this patch?
Comment 31 pdpd 2011-07-16 13:07:38 PDT
In Thunderbird 5, this same problem affects basic forwarding and replying to messages, composing new messages, and opening messages in a new window -- which arguably are even more serious usability issues than their counterparts in Firefox:  See bug 669659 and discussion at http://getsatisfaction.com/mozilla_messaging/topics/thuderbird_5_wont_open_new_window_on_mac_for_writing_or_replying_with_two_monitors
Comment 32 Julz 2011-07-18 21:39:59 PDT
@Steven Currently the easiest way to resolve this for me, and I think for Steven and others with the same problem, is to go to the Arrangement tab in Display Preferences and align the secondary monitor (for me it's my laptop display) with the top of the primary monitor (my Samsung 24").  Once this is done the problem doesn't occur.  I has to do with what John Hawkinson noticed and produced a "first" patch for in comment #23 and then Devon Hubbard commented on in comment #24.  See attachment #533901 [details] on that comment for two temporary solutions.

As a side note this particular affects any products using the Gecko "windowing" libraries.  If I can call it that.  So Firefox, Thunderbird, probably Sunbird (haven't checked this yet) and perhaps Chandler and more ...

Hope this helps you Steven.  It sure helped me.  Prior to finding this bug I was blaming the new Conversations extension for destroying my beautiful Thunderbird setup.
Comment 33 Roland Tanglao :rolandtanglao 2011-07-19 13:00:10 PDT
(In reply to comment #32)
> @Steven Currently the easiest way to resolve this for me, and I think for
> Steven and others with the same problem, is to go to the Arrangement tab in
> Display Preferences and align the secondary monitor (for me it's my laptop
> display) with the top of the primary monitor (my Samsung 24").  Once this is
> done the problem doesn't occur.  

Confirmed on my MacBook Pro 2010!
1. go to the Arrangement tab in Display Preferences and align the secondary monitor (e.g. my laptop display) with the TOP of the primary monitor 
RESULT: Problem DOES NOT OCCUR i.e. you can see new windows being created

2. go to the Arrangement tab in Display Preferences and align the BOTTOM of the secondary monitor (e.g. my laptop display) with the BOTTOM of the primary monitor 
RESULT: Problem occurs i.e. you can't see new windows being created
Comment 34 John Hawkinson 2011-07-19 13:04:56 PDT
This isn't really news, I don't think we need more affirmations of the problem scenario -- it is pretty well understood at this point.

Is there someone other than Josh who can review this? Perhaps Scott Greenlay since it was his patch that introduced this problem?

Would it make life easier for Josh if I or someone else did some work to improve the patch?  I offered to do so on June 17 but concluded from the response that it was not useful. Perhaps the calculus has changed?

Alternatively, do we have a general ida of which must stuff is in Josh's review queue and when he is likely to get to this?

Thanks.
Comment 35 John Hawkinson 2011-07-19 14:02:53 PDT
Whoops. Roland, I did not notice that you changed the summary. Your change is, in my view, not correct. It is not a requirement that the bottom of the secondary and primary monitors be aligned. The current code gets into trouble whenever negative coordinates are involved, which is in many more cases than that.
Comment 36 Roland Tanglao :rolandtanglao 2011-07-19 14:18:59 PDT
(In reply to comment #35)
> Whoops. Roland, I did not notice that you changed the summary. Your change
> is, in my view, not correct. It is not a requirement that the bottom of the
> secondary and primary monitors be aligned. The current code gets into
> trouble whenever negative coordinates are involved, which is in many more
> cases than that.
You are right, jhawk.

Any non top aligned position will reproduce the problem. just did another quick test to confirm!

revised steps to reproduce:

go to the Arrangement tab in Display Preferences and align the TOP of the secondary monitor  so that's it NOT aligned with the top of the primary. Any position that's not TOP aligned will reproduce the problem.

Changed the summary accordingly.
Comment 37 John Hawkinson 2011-07-19 14:23:23 PDT
Thanks. I bet you can get it with top alignment with the correct sizes of monitor, but that's splitting hairs and probably not a useful use of our time to come up with such scenarios.

Any thoughts on making progress on the review?
Comment 38 Josh Aas 2011-08-13 06:49:35 PDT
Sorry for the delay, I actually looked at this for a while but ran out of time before I could determine that it was correct. Switching the review request to Benoit Girard.
Comment 39 Benoit Girard (:BenWa) 2011-08-13 09:27:39 PDT
(In reply to John Hawkinson from comment #23)
> I think my patch is not quite right, though. It ends up putting these
> windows on the center screen rather than the side screen (a VAST improvement
> over having no window at all!!)

Thanks for the patch and all the info you posted. I agree that your patch is an improvement but I think what we want to do is check the window position against all the available monitors. Let me know if you have time to make this improvement if not I will take a look. I'm in the middle of moving so don't have an extra monitors to work on this but I can take a look early next week.
Comment 40 Benoit Girard (:BenWa) 2011-08-16 08:14:44 PDT
I took a brief look and we can use NSScreen screens to check the desired window rect against every screen instead of only the mainScreen.

Anyone interested in extending the current patch to do this? If no one is available I will find some time.
Comment 41 John Hawkinson 2011-08-16 21:18:22 PDT
Yes, I can take a look in the next few days. What branch should this work be against?
Comment 42 Josh Matthews [:jdm] 2011-08-16 21:27:25 PDT
mozilla-central is the repo you want.
Comment 43 Troy E. Lanes 2011-08-17 13:11:19 PDT
still present in FF 6.0
Comment 44 Wayne Mery (:wsmwk, NI for questions) 2011-08-19 08:15:09 PDT
*** Bug 669659 has been marked as a duplicate of this bug. ***
Comment 45 Benoit Girard (:BenWa) 2011-08-19 11:41:29 PDT
Created attachment 554487 [details] [diff] [review]
patch

Check all the monitors for a suitable location to open the window then center the window on that monitor, default to the center screen if aRect doesn't overlap with any screen.

Used part of the patch from John Hawkinson if the window did not fit within the main screen.
Comment 46 Steven Michaud [:smichaud] (Retired) 2011-08-19 12:41:34 PDT
Comment on attachment 554487 [details] [diff] [review]
patch

This looks fine to me (though since I don't have two monitors, I can't test it).

But the following comment seems wrong:

+  // If the right/bottom edge of the window is over the edge of the screen,
+  // then set window to start at the left/top edge.

Shouldn't it be something like this?

If the left/top edge of the window is off the screen in either direction, then set the window to start at the left/top edge of the screen.
Comment 47 Benoit Girard (:BenWa) 2011-08-19 12:56:59 PDT
Created attachment 554516 [details] [diff] [review]
patch (fix comment)

You're right I fixed the comment. Carrying forward r+.
Comment 48 Benoit Girard (:BenWa) 2011-08-19 12:59:35 PDT
Putting this patch on try-server just to be safe. I will request qawanted to verify the fix once it lands.
Comment 49 Mozilla RelEng Bot 2011-08-19 16:30:52 PDT
Try run for ad987d034a36 is complete.
Detailed breakdown of the results available here:
    http://tbpl.allizom.org/?tree=Try&usebuildbot=1&rev=ad987d034a36
Results (out of 35 total builds):
    success: 30
    warnings: 5
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/b56girard@gmail.com-ad987d034a36
Comment 50 Benoit Girard (:BenWa) 2011-08-20 13:14:12 PDT
Comment on attachment 533878 [details] [diff] [review]
Don't assume that screenBounds are positive!

I included these changes in the final patch but this patch is missing code to check the position against all the monitors.
Comment 51 Benoit Girard (:BenWa) 2011-08-20 13:18:02 PDT
Pushed to m-i:
http://hg.mozilla.org/integration/mozilla-inbound/rev/be2eb19328c4
Comment 52 Matthias Versen [:Matti] 2011-08-21 10:30:30 PDT
*** Bug 680719 has been marked as a duplicate of this bug. ***
Comment 53 :Ms2ger (⌚ UTC+1/+2) 2011-08-21 11:31:01 PDT
http://hg.mozilla.org/mozilla-central/rev/be2eb19328c4
Comment 54 Anthony Ricaud (:rik) 2011-08-21 15:14:58 PDT
This looks like a dupe of bug 632749.
Comment 55 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-08-24 11:59:23 PDT
*** Bug 632749 has been marked as a duplicate of this bug. ***
Comment 56 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-08-24 12:05:41 PDT
Can someone who was able to reproduce this bug before please confirm if it has been fixed? Thanks
Comment 57 Troy E. Lanes 2011-08-24 13:47:05 PDT
I tested nightly 9.0a1 (2011-08-24) with non-top aligned displays with the right external display being the primary display on OS X 10.7.1.  The issue appears to be resolved.  I could not duplicate the original issue.
Comment 58 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-08-24 14:10:05 PDT
Marking VERIFIED based on comment 57.
Comment 59 John Hawkinson 2011-08-27 12:46:41 PDT
(In reply to Benoit Girard (:BenWa) from comment #45)

Sorry for not actually looking at this...when you got to the patch first, I reprioritized some other work. While this looks fine, I do have some comments on the behavior of new windows.

With Firefox 4, hitting Cmd-U for View Source opened a 600x500px window on the Main Screen. With my patch, hitting Cmd-U opened a full-screen window on farthest left screen. With Nightly 9.0a1 Gecko/20110827, Cmd-U opens a 600x500px window on the Main Screen.

I guess my expectation is that an ancillary window should open on the same screen that the main browser window is on, rather than on the Main Screen. For instance, I often have Firefox running on the left screen, and other apps on the Main Screen (center), and other apps on the right right screen. Having new FF windows pop up on the Main Screen seems wrong to me.

I guess the fact that the window showed up on the same screen that FF was on with my patch was really an accident -- merely because I happened to have FF on the leftmost screen.

I suppose this is outside the scope of this bug, and I'm not really going to file anything for it. Just kind of rambling.
Comment 60 Benoit Girard (:BenWa) 2011-08-27 14:27:51 PDT
(In reply to John Hawkinson from comment #59)

My patch tries to honor the position that the new window is created while fitting the window to the closest matching monitor. If my patch doesn't honor the position properly then it would be a problem in my patch. Otherwise if the wrong position is request then we should fix this in a separate bug.
Comment 61 Devon Hubbard 2011-08-28 16:10:42 PDT
I've tested the nightly from comment #49...
>http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/b56girard@gmail.com-ad987d034a36

The original problem (that is still very reproducible with public Firefox 6.0) is fixed with a slight side effect.  Windows are opening on the main monitor now as expected; and not hidden as reported in this bug.  However, if no window is already open and visible on the right hand monitor, subsequent windows are opened on the right hand monitor as if they were vertically sized to fit on the left hand monitor.

problem summary:
The patch is correctly created new windows now, but windows are sized for the lowest screen size on the system and not sized correctly for the screen the window is actually appearing on.

monitor layout:
- left hand monitor is 1440x900
- right hand monitor is 1920x1200, main menu bar on this monitor

Example steps:

1) Open a browser window on the right hand monitor (1920x1200).
2) Expand vertically to fill the right hand monitor.
3) Close that browser window.
4) Press CMD+N to create a new browser window.  Confirm that it filled the screen vertically as expected.
5) Close the browser window.
6) Open Tools > Downloads window and position on left hand monitor.
7) Press CMD+N to create a new browser window.

Result:
A browser window is created on the right-hand monitor *but* is vertically sized no taller than the left hand monitor.

Note:
This is not an issue where Firefox is remembering the previous window size for subsequent windows.  In fact, if a browser window is already present on the right hand monitor, subsequent windows created on the right hand monitor are sized correctly for the right hand monitor.  It is only when no windows are present on the right monitor that new windows sized incorrectly.

(apologies for the somewhat redundant right/left hand monitor references, but I wanted this description to be as clear as possible.)

If I am checking the wrong build, please let me know.  Thanks.
Comment 62 Devon Hubbard 2011-08-28 17:20:20 PDT
Created attachment 556440 [details]
644733_nightlyfix_example movie

follow up to comment #61
screen recording example of window size/position bug fix across two monitors.
Comment 63 Benoit Girard (:BenWa) 2011-08-28 17:42:16 PDT
(In reply to Devon Hubbard from comment #61)
Thanks for the report, filed bug 682753.
Comment 64 Wayne Mery (:wsmwk, NI for questions) 2011-09-06 07:38:59 PDT
*** Bug 680434 has been marked as a duplicate of this bug. ***
Comment 65 Wayne Mery (:wsmwk, NI for questions) 2011-09-06 07:42:06 PDT
Comment on attachment 554516 [details] [diff] [review]
patch (fix comment)

can this be landed for Aurora, given that it's a regression, and has baked for a few weeks?  (and seems like low risk, although I'm not in a great position to judge)
Comment 66 Wayne Mery (:wsmwk, NI for questions) 2011-09-06 07:49:58 PDT
*** Bug 645512 has been marked as a duplicate of this bug. ***
Comment 67 Wayne Mery (:wsmwk, NI for questions) 2011-09-06 07:50:34 PDT
*** Bug 609405 has been marked as a duplicate of this bug. ***
Comment 68 Wayne Mery (:wsmwk, NI for questions) 2011-09-06 07:56:51 PDT
Bug 644345 cites http://support.mozilla.com/en-US/questions/803320 which shows 112 people interested in solution

And there are 6 bugs duped to bug 632749 that I should have duped to here.
Comment 69 christian 2011-09-08 14:22:01 PDT
Comment on attachment 554516 [details] [diff] [review]
patch (fix comment)

This does meet the criteria for aurora. This will get fixed once it bubbles up through the normal development process
Comment 70 Jason Fager 2011-09-09 06:36:35 PDT
If a pure bugfix for a 4.0 regression doesn't qualify for aurora, what does?  For that matter, why isn't it tracked for the beta channel?  Are these criteria spelled out anywhere?
Comment 71 Wayne Mery (:wsmwk, NI for questions) 2011-09-15 09:51:20 PDT
*** Bug 633901 has been marked as a duplicate of this bug. ***
Comment 72 Matthias Versen [:Matti] 2011-09-22 22:41:33 PDT
*** Bug 688408 has been marked as a duplicate of this bug. ***
Comment 73 Wayne Mery (:wsmwk, NI for questions) 2011-09-28 05:55:11 PDT
*** Bug 689863 has been marked as a duplicate of this bug. ***
Comment 74 Matthias Versen [:Matti] 2011-10-11 07:57:17 PDT
*** Bug 693552 has been marked as a duplicate of this bug. ***
Comment 75 Les Orchard [:lorchard] 2011-11-29 10:40:51 PST
Is there another bug related to being unable to open additional windows on Mac? On Aurora 10.0a2, bug 632749 still happens for me and it was marked dupe of this one.
Comment 76 Benoit Girard (:BenWa) 2011-11-29 10:44:57 PST
(In reply to Les Orchard [:lorchard] from comment #75)
> Is there another bug related to being unable to open additional windows on
> Mac? On Aurora 10.0a2, bug 632749 still happens for me and it was marked
> dupe of this one.

I just tested this on Nightly and it WFM. Please file a new bug, CC me and list detailed STR and your monitor arrangement and I'll take a look.

Note You need to log in before you can comment on or make changes to this bug.