Can't open new windows if any windows are on a secondary monitor & primary and secondary are NOT TOP aligned (dual screen) [Mac]

VERIFIED FIXED in Firefox 9

Status

()

Core
Widget: Cocoa
--
major
VERIFIED FIXED
7 years ago
6 years ago

People

(Reporter: Devon Hubbard, Assigned: BenWa)

Tracking

(Blocks: 1 bug, {regression})

Trunk
mozilla9
x86_64
Mac OS X
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox6 affected, firefox7 affected, firefox8 affected, firefox9 fixed)

Details

Attachments

(5 attachments)

(Reporter)

Description

7 years ago
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.
Please try http://support.mozilla.com/en-US/kb/Safe+Mode

Updated

7 years ago
Version: unspecified → Trunk

Comment 2

7 years ago
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
(Reporter)

Comment 3

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

Comment 4

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

6 years ago
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! :-)

Updated

6 years ago
Keywords: regression, regressionwindow-wanted
(Reporter)

Comment 6

6 years ago
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.
Summary: Can't open new windows → Can't open new windows if any windows are on a secondary monitor

Comment 7

6 years ago
Reporter, do you have anything new to add about this issue?
(Reporter)

Comment 8

6 years ago
No.  Other than it is still reproducible using the steps noted above (comment #6)
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
(Reporter)

Comment 11

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

Comment 17

6 years ago
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.
Devon, can you try using the following tool to find a regression range for this bug?

http://harthur.github.com/mozregression/

Comment 19

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

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

Comment 21

6 years ago
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.
Thanks John and Devon for finding the regression range -- a 24 hour window is usually "good enough" for developers to isolate the issue.
Keywords: regressionwindow-wanted

Comment 23

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

Comment 24

6 years ago
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.
Component: General → Widget: Cocoa
Product: Firefox → Core
QA Contact: general → cocoa
Attachment #533878 - Flags: review?(joshmoz)

Updated

6 years ago
Blocks: 413277
See also bug 632606 which is probably a dupe of this one now.

Updated

6 years ago
Duplicate of this bug: 632606
Blocks: 236647
Summary: Can't open new windows if any windows are on a secondary monitor → Can't open new windows if any windows are on a secondary monitor [Mac]

Comment 27

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

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

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

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

6 years ago
@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.
(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
Summary: Can't open new windows if any windows are on a secondary monitor [Mac] → Can't open new windows if any windows are on a secondary monitor & bottom of secondary is aligned with bottom of primary [Mac]

Comment 34

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

6 years ago
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.
(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.
Summary: Can't open new windows if any windows are on a secondary monitor & bottom of secondary is aligned with bottom of primary [Mac] → Can't open new windows if any windows are on a secondary monitor & primary and secondary are NOT TOP aligned [Mac]

Comment 37

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

Updated

6 years ago
Attachment #533878 - Flags: review?(joshmoz) → review?(bgirard)

Comment 38

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

Comment 39

6 years ago
(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.
Assignee: nobody → bgirard
(Assignee)

Comment 40

6 years ago
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.
Whiteboard: [good first bug][mentor=bgirard@mozilla.com]

Comment 41

6 years ago
Yes, I can take a look in the next few days. What branch should this work be against?
mozilla-central is the repo you want.

Comment 43

6 years ago
still present in FF 6.0
Duplicate of this bug: 669659
(Assignee)

Comment 45

6 years ago
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.
Attachment #554487 - Flags: review?(smichaud)
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.
Attachment #554487 - Flags: review?(smichaud) → review+
(Assignee)

Comment 47

6 years ago
Created attachment 554516 [details] [diff] [review]
patch (fix comment)

You're right I fixed the comment. Carrying forward r+.
(Assignee)

Comment 48

6 years ago
Putting this patch on try-server just to be safe. I will request qawanted to verify the fix once it lands.

Comment 49

6 years ago
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
(Assignee)

Comment 50

6 years ago
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.
Attachment #533878 - Flags: review?(bgirard) → review-
(Assignee)

Comment 51

6 years ago
Pushed to m-i:
http://hg.mozilla.org/integration/mozilla-inbound/rev/be2eb19328c4
Whiteboard: [good first bug][mentor=bgirard@mozilla.com] → [inbound]
Duplicate of this bug: 680719
http://hg.mozilla.org/mozilla-central/rev/be2eb19328c4
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → mozilla9
This looks like a dupe of bug 632749.
Duplicate of this bug: 632749
Can someone who was able to reproduce this bug before please confirm if it has been fixed? Thanks

Comment 57

6 years ago
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.
Marking VERIFIED based on comment 57.
Status: RESOLVED → VERIFIED

Comment 59

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

Comment 60

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

Comment 61

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

Comment 62

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

Updated

6 years ago
Blocks: 682753
(Assignee)

Comment 63

6 years ago
(In reply to Devon Hubbard from comment #61)
Thanks for the report, filed bug 682753.
No longer blocks: 682753
(Assignee)

Updated

6 years ago
Blocks: 682753
Summary: Can't open new windows if any windows are on a secondary monitor & primary and secondary are NOT TOP aligned [Mac] → Can't open new windows if any windows are on a secondary monitor & primary and secondary are NOT TOP aligned (dual screen) [Mac]
Duplicate of this bug: 680434
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)
Attachment #554516 - Flags: approval-mozilla-aurora?
Duplicate of this bug: 645512
Duplicate of this bug: 609405
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.
(Assignee)

Updated

6 years ago
status-firefox6: --- → affected
status-firefox7: --- → affected
status-firefox8: --- → affected
status-firefox9: --- → fixed

Comment 69

6 years ago
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
Attachment #554516 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora-

Comment 70

6 years ago
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?
Duplicate of this bug: 633901
Duplicate of this bug: 688408
Duplicate of this bug: 689863
Duplicate of this bug: 693552
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.
(Assignee)

Comment 76

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