50686 - Dialogs and Windows centered on screen instead of to parent window

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Greg Breland]

Some dialogs and new windows are centered on the physical screen.  This is very 
annoying on Dual monitor setups or when you are running more than one window 
tiled side by side.  So far, I have found these windows/dialogs to be at fault:

Basic Auth Password Dialog
Customize Sidebar

Some dialogs/windows dont center at all, but appear in the top left corner of 
the physical screen.  These should at least appear based on the top left corner 
of the parent window.  However, centering would be better.  These dialogs 
include:

Customize Sidebar Preview
IRC Chat (when launched)

Lastly, some dialogs rember where they were last positioned.  This makes a lot 
of sense for the main windows such as Navigator, Mail, IRC, Composer, etc.  
However, even some dialogs rember where they were last placed, and this causes 
problems.  For example, the "Find on this page" dialog box will rember where it 
last was.  This is not a good use of this feature because if you have a browser 
open in window one and you choose the "Find" option, the user may not notice 
the dialog that shows up on screen 2.

I think all windows main windows should rember their physical position.  I 
think all dialog boxes should rember their position realitive to their parent 
window.

Of couse, all final cordinates should be bound checked to see if they fall 
outside of the screen coridinates.

Also refer to bug #49402

Comment 1

[Asa Dotzler [:asa]]

setting bug status to New

Comment 2

[Greg Breland]

Also, anyone working on a fix for this, should probably take a look at Bug# 
36550 as anything dealing with physical measurements of the display will be 
affected by it.  I can see this bug causing major problems with a dialog 
centering alogarithm if not accounted for.

Comment 3

[Viswanath Ramachandran]

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy

Comment 4

[Paul Chen]

nav triage team:

We should look into this, marking nsbeta1, mozilla0.9, reassigning to pchen

Comment 5

[Paul Chen]

Really annoying, but don't think we'll get to this for mozilla0.9. Marking
nsbeta1-, resetting target milestone

Comment 6

[Paul Chen]

Reassigning to danm because I think he owns all these window positioning bugs.
At any rate, I blame him! ;-) Resetting priority, removing nsbeta1- keyword.
Allow xptoolkit to triage as necessary

Comment 7

[Dan M]

You know, he has a point. We could interpret the persistent size data of 
dependent windows as local to the parent window. That'd be kind of slick, and not 
too hard. We should do that. I'm adding it to my burgeoning 1.0 milestone list, 
which is not very realistic of me, and adding the "helpwanted" keyword, which is 
more so.

Comment 8

[selmer (gone)]

nom catfood, this may be the generic solution to all the dialog positioning bugs...

Comment 9

[Akkana Peck]

This should apply to Linux as well.  Linux dialog placement has other problems,
though; a lot of our dialogs come up at position (0, 0) on the screen, others
are centered on the screen, and still others are centered on an existing window
(not necessarily the parent window of the dialog).  See my comment of 4/2/2001
in bug 47332 for some specific examples.

Comment 10

[sairuh (rarely reading bugmail)]

mcafee filed bug 74325 for dialogs appearing at (0,0).

Comment 11

[sairuh (rarely reading bugmail)]

*** Bug 74325 has been marked as a duplicate of this bug. ***

Comment 12

[Akkana Peck]

Would mcafee's suggested fix for bug 74325 make a reasonable workaround if we're
not going to get a real fix any time soon?  We'd look a lot more professional if
our dialogs came up in consistent locations, if there's an easy quick fix.

Comment 13

[Chris McAfee]

I recently applied the fix to the find dialog, if that
works for people we can try that for other dialogs.

Comment 14

[Dan M]

mcafee's suggested fix, if it works, is real enough. I think it'll tend to 
position intrinsically sized windows in a position not quite centered but 
probably reasonable enough. And of course automatic centering would render 
bootless any persistence of position. But it's worth looking at, sure.

Comment 15

[Dan M]

sfraser sez: along with interpreting persistent position of dependent/transient/
child windows to be relative to the parent window, we should also implement an 
automatic 'default position' attribute, like the Mac OS's window positioning 
flags. So it should be possible for a window to position itself where last 
placed, relative to its parent, or on first invocation, in a decent "alert" 
position relative to its parent.

Comment 16

[Simon Fraser [no longer active]]

FYI, some useful default positioning flags would be:
* None
* Center on parent window's screen (main screen if no parent window)
* Alert position on parent window's screen (ditto)
  [alert position is 1/3 of the way down the screen, roughly]
* Center on parent window
* Alert position on parent window
* Stagger on parent window

I think this should be either an attribute on the <window> tag, and/or passable 
via the openDialog call.

Comment 17

[:deanis74]

In most Windows apps, dialogs and messageboxes come up in the center of the
screen.  The original report seems to be more of a problem with multiple monitor
support.

Comment 18

[Chad Austin]

*** Bug 92648 has been marked as a duplicate of this bug. ***

Comment 19

[Chad Austin]

oops...

Comment 20

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 21

[Dan M]

  (Fixed) bug 113283 was essentially this bug, so I'm calling this one fixed,
too. Dependent windows (dialogs and alerts, pretty much), if requested to be
centered, are now centered on their parent window, rather than to the screen. If
requested to have position persistence, that's now done relative to the parent
window, too. And if both are requested, position persistence will override
centering. Meaning that it'll come up centered the first time and subsequent
times it'll come up at the same position at which it was left relative to its
parent in its last invocation.
  All this can be turned on or off: it's controlled by feature flags in the
window.openDialog call (the now somewhat inappropriately named "centerscreen"
flag) and by attributes on the window tag in the window XUL ("persist",
"screenX" and "screenY"). Meaning that the backend support is all in, but
individual dialogs have to apply it individually.
  This bug mentions several dialogs by name. My interest in it is the backend
support, which I claim is now in. I claim it'll be mostly all good now. But if a
particular dialog still seems broken, it'll want a bug all its own, one for each
such dialog, filed against the XP Apps group.