883859 - [10.9] Dialogs do not open on the screen where Firefox is active

Status: NEW

(Core :: Widget: Cocoa, defect, P3)

Description

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

10.9 13A476u / Firefox 21.0

STR:

1) Open Firefox, open a window, move it to the external display, make sure it is active
2) Hit Command-, to open the preferences OR trigger any popup window such as the Persona login box

Expected:

The window appears on the same screen where the Firefox window is open and where the menu bar is active.

Actual:

The window opens on the other display.

So the 'main screen' is a bit of a blurry concept on 10.9 as all screens now get a menu bar and dock. So there really is not a main screen anymore.

If you move Firefox to the external display and have a Firefox window active there, you will see the (Firefox) menu bar active on that screen. So that is now effectively the main screen where windows should open.

Comment 1

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Hmm interesting. I just noticed that Safari actually does the same. So maybe this is an OS bug and not an application bug. Will have to try this on newer betas and file  bug with Apple if this persists.

Comment 2

[Steven Michaud [:smichaud] (Retired)]

This still happens in Firefox (22.0.1) in Mavericks DP7 (13A569).  But Safari's behavior is now much stranger:

If you run Safari and move it to the other display without first having opened its preferences dialog, the dialog will open on the other display.  But if you move Safari back to the first display, you will never see its preferences dialog again (though the Safari browser window still loses focus, and you sometimes see its shadow).

Definitely an Apple bug.  But it's possible that by the release Safari will have been hacked to behave "correctly", and Firefox will still behave "incorrectly".

Comment 3

[Steven Michaud [:smichaud] (Retired)]

Note that this only happens with non-native dialogs that open in separate windows (like the Preferences and Bookmarks dialogs) -- not with new browser windows or with native modal dialogs (like the file picker).

Comment 4

[Steven Michaud [:smichaud] (Retired)]

DP8 (13A584), which I just installed, hasn't changed anything that I described in comment #2 and comment #3.

Comment 5

[u279076]

What's the current status of this bug? If it affects other applications as well should this be a Tech Evangelism issue?

Comment 6

[Steven Michaud [:smichaud] (Retired)]

I haven't yet tested in the GM.  But I should be able to do that in the next few days.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

I've just tested FF 24 in the OS X 10.9 GM and found that its behavior is still as described in comment #0 and comment #3.

But Safari also still behaves incorrectly -- exactly as it did in DP8 (as I described in comment #2).

> If it affects other applications as well should this be a Tech Evangelism issue?

Who would we "evangelize"?  Apple?  It's clearly their bug.

Comment 8

[u279076]

(In reply to Steven Michaud from comment #7)
> Who would we "evangelize"?  Apple?  It's clearly their bug.

Exactly, do we have acknowledgement from Apple that they are aware of this issue?

Comment 9

[Steven Michaud [:smichaud] (Retired)]

Tomorrow I'll open a bug with Apple.  I'll mention both Firefox's and Safari's behavior.

Apple generally doesn't acknowledge bug reports ... but we'll at least have met our obligation.

Comment 10

[Steven Michaud [:smichaud] (Retired)]

I've opened a bug with Apple.  Here's the text of my report:

On OS X Mavericks (10.9), on a dual monitor system, non-native dialog
windows often open on the "wrong" screen.  This bug effects Firefox
and the current versions of both Chrome and Opera -- though in
different ways.  By "non-native dialog windows" I mean those that
aren't provided by the OS (like the native file picker, print and page
setup dialogs).  This bug still happens in the Mavericks GM (134A598).

In Firefox, non-native dialog windows always open on the "main"
screen, regardless of which screen the active browser window is
displayed on.  To see this bug choose Firefox : Preferences or History
: Show All History.

In Chrome and Opera, non-native dialog windows always open on the
screen where the first browser window was created when the browser
started.  To see this bug in Chrome or Opera choose Edit : Spelling
and Grammar : Show Spelling and Grammar.  (In Chrome you first have to
put the cursor in a text field.)

Safari behaves even more strangely:

If you move a Safari browser window from one screen to another,
non-native dialog windows don't appear at all -- or rather they seem
to be displayed somewhere "offscreen", since the main browser window
loses focus.  To see this bug in Safari choose Safari : Preferences.

This bug was first reported at
https://bugzilla.mozilla.org/show_bug.cgi?id=883859, and will be
followed up there.

Comment 11

[u279076]

Thanks Steven. Question now is what can we do on our end, and if nothing should this be moved to Tech Evang or just resolved INVALID.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

I think we should wait to see what Apple does.

With luck they'll fix the bug for everyone.  But it's also possible they'll "fix" the bug in Safari only, and other browser vendors will be left to fend for themselves.

One thing that's certain is that they *will* do something -- they won't leave Safari's behavior as broken as it currently is.

We should be on the lookout for an update to Mavericks that comes out shortly after its release (if Apple's good angel prevails), or an update to Safari (if their bad angel does).

Comment 13

[Steven Michaud [:smichaud] (Retired)]

Another thing to watch out for:

Safari, Chrome and Opera are now all WebKit browsers, so it's possible *that's* where Apple's "fix" will land -- which won't help us.

If we *are* left holding the bag, we'll (presumably) have to hack out some kind of workaround.

Comment 14

[Steven Michaud [:smichaud] (Retired)]

Today Apple released Mavericks as a free upgrade for all versions of OS X 10.6.8 and up.  The Mavericks "release" has a different build ID (13A602) than the GM (build 13A598).  I'll be testing the "release" to see if its behavior here is different from the GM's.

Comment 15

[Steven Michaud [:smichaud] (Retired)]

The behavior with the Mavericks release (actually Build 13A603) is still exactly the same as I've described it in comment #10 (my report to Apple).