BUILD: Current trunk STEPS TO REPRODUCE: 1) Open the Clear Recent History window 2) Switch to a different space ACTUAL RESULTS: The window follows you onto the new space, but only if there are any Firefox windows somewhere on that space EXPECTED RESULTS: The window does NOT follow me around, especially if I'm trying to use some other app on the other space. The fact that there's a download manager window off in the corner doesn't mean I want this dialog there. It looks like this is a regression from bug 309406, and I wonder why we made a significant behavior change (app-modal vs window-modal is a big difference in user interaction!) to fix a cosmetic issue...

This actually isn't a bug. The same thing happens with Safari. And (I think) it makes sense for an app-modal dialog to behave as you describe. To reproduce this in Safari: 1) Start Safari and open two windows. 2) Drag one of these windows to another space. 3) Choose Safari : Quit Safari, which brings up an app-modal dialog. This dialog will follow you into any space that contains at least one Safari window.

Yeah, but why is this dialog app-modal? It's not on other OSes, and I don't think it should be on Mac. In addition to the obvious problems with app interaction, it leads to this bizarre behavior.

Possibly related to bug 493559. This dialog box is built using the preferences XUL stuff, which is normally used for Preferences/Options which currently is app-model. But this dialogbox doesn't need to be app-model. (But even Preferences//Options should not have to be so...)

I meant to nominate this earlier and totally forgot... This has been a major annoyance for me, actually.

See also bug 509124 which is about that the dialog doesn't get listed by getXULWindowEnumerator which blocks our Mozmill tests.

This reverses what was changed in bug 309406. I think the issue with centerscreen on Mac may have been fixed since bug 309406, although I couldn't find any bug to confirm that. But with this patch, the dialog opens normally (in the right place, and only in one space) for me, as expected.

IIRC, bug 309406 was not reliably reproducible. Without more confidence that the underlying issue really has been solved, I'm not sure I'm comfortable just reverting this workaround. Have you tested all of the scenarios listed in that bug (windows open, shutdown, etc.)? It would be nice to find a "fixed in" range to see what fixed it, but I suppose that might be more trouble than it's worth.

More testing... I can't reproduce it with an existing window open. But, with no window (which I must have missed testing last time), the dialog isn't visible at all (but it is opened). This doesn't seem the same as bug 309406, which described just an odd placement of the dialog. Additionally, there's a warning thrown from nsWindowMediator.cpp (line 592): "getting z level of unregistered window". I assume that means its trying to use the hidden window as a parent. So from what I can tell, the options are: * Use nsIWindowMediator to get the top-level window and use that as a parent for window-modal. If there is none, open as app-modal. Not sure what the UX people will think of that. It also assumes that the window-modal dialog won't open in the wrong position (which I couldn't duplicate, but doesn't mean it doesn't happen). * Keep the current app-modal behavior

After some discussion with mstange on IRC: In the case where there is no window, another option is to make the dialog non-modal. This should fix any weird dialog behavior when switching spaces. This would be only for OSX - other platforms can keep their current behavior. I also asked Limi, who is fine with this approach from a UX standpoint (window-modal when there's a window, non-modal otherwise). Paraphrased: <limi> it should not show on all spaces, ever <limi> it should show on the space you initiated it from I think that for the UX gains we get from making it not app-modal, its worth potentially having the odd person with the dialog open in a position that isn't centered on screen. Thoughts?

Cannot Reproduce Windows 10 or Mac 10.11 Version 47.0.1 Build ID 20160623154057 User Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0