79849 - Downloading 'Advanced' dialog should be centered on the parent dialog

Status: VERIFIED FIXED

(Core Graveyard :: File Handling, defect)

Description

[Simon Fraser [no longer active]]

The dialog that comes up when you hit 'Set Default...' in the download dialog 
comes up in the top left of the screen (ick!). It should be centered on the 
parent dialog. Bonus points if you persist its position.

Comment 1

[Bill Law]

Hmmm.  Works for me.  Is it in the wrong place only when you encounter the other
problem (with blank MIMEType for .sit files)?  The failing JS wouldn't get to
the "moveToAlertPosition" call in that case.

Comment 2

[basic]

Changing platform

Comment 3

[sairuh (rarely reading bugmail)]

isn't this a cross-platform issue?

Comment 4

[Simon Fraser [no longer active]]

All platforms

Comment 5

[Bill Law]

WFM on Win2K, fails on Mac.  Not sure what makes it break.

Comment 6

[sairuh (rarely reading bugmail)]

spam: over to File Handling.

Comment 7

[Bill Law]

Attachment: fix

Adds sizeToContent() and moveToAlertPosition() calls to both the "New Type" and
"Edit Type" dialogs.  I need to add an overlay for globalDialogOverlay.xul to
the "Edit Type" dialog (to get the definition of those functions).

Comment 8

[Samir Gehani]

Why not just include dialogOverlay.js using a <script> tag?

Comment 9

[Blake Ross]

Seems like there should be a generic way to specify this, i.e. as an openDialog
argument, or it should be built into <dialog/> and specifiable.

Comment 10

[Simon Fraser [no longer active]]

Yes. I've tried to convince danm that this would be a good thing. Mac OS has:

enum {
    kWindowNoPosition           = 0x0000,
    kWindowDefaultPosition      = 0x0000,                       /* used by 
StandardAlert*/
    kWindowCenterMainScreen     = 0x280A,
    kWindowAlertPositionMainScreen = 0x300A,
    kWindowStaggerMainScreen    = 0x380A,
    kWindowCenterParentWindow   = 0xA80A,
    kWindowAlertPositionParentWindow = 0xB00A,
    kWindowStaggerParentWindow  = 0xB80A,
    kWindowCenterParentWindowScreen = 0x680A,
    kWindowAlertPositionParentWindowScreen = 0x700A,
    kWindowStaggerParentWindowScreen = 0x780A
};

Comment 11

[sairuh (rarely reading bugmail)]

see bug 111035 comment 2 and bug 111035. if bug 86640 [help app dlg redesign] is
implemented that way, the Advanced [formerly Set Default] button will be
removed, and this bug would be moot, methinks.

Comment 12

[Bill Law]

Not quite, Sarah.  The dialogs are also mis-positioned when opened from the
helper app pref panel.

Samir, I added the dialogOverlay.xul overlay becaues I think I also might want
to pick up the stuff from the overlay (default buttons, etc.).  There is a
slight performance hit with the .xul, though.  I'll change it and make sure it
still works OK.

I agree about making this easier.  There are a *lot* of
sizeToContent()/moveToAlertPosition() calls out there.  I think an attribute on
the dialog would be nicer (with this one being the default).  How about we open
a new bug asking for that?  The fix for that would have to go find all the
existing code that does the sizeToContent/moveToAlertPosition and that would fix
this one up, too.

Comment 13

[Bill Law]

Attachment: updated patch, uses <script> instead of overlay

Comment 14

[Bill Law]

I still need some reviews on this.  Please?

Comment 15

[Samir Gehani]

r=sgehani

Comment 16

[Dan M]

See also bug 113283. It shouldn't affect the patch in this bug -- if you were
already repositioning the window with script, it should continue to work. But
the patch in that bug is another option for you.

Comment 17

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 59802 [details] [diff] [review]
updated patch, uses <script> instead of overlay

sr=[e-mail]

Comment 18

[Bill Law]

fixed

Comment 19

[sairuh (rarely reading bugmail)]

verified fixed using 2002.01.29.1x comm verif bits on linux rh7.2, win2k and mac
10.1.2.