Closed Bug 79849 Opened 24 years ago Closed 23 years ago

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


(Core Graveyard :: File Handling, defect)

Not set


(Not tracked)



(Reporter: sfraser_bugs, Assigned: law)




(1 file, 1 obsolete file)

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.
Blocks: 78106
Summary: Downloading 'Set Deafault' dialog should be centered on the parent dialog → Downloading 'Set Default' dialog should be centered on the parent dialog
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.
Changing platform
Hardware: All → Macintosh
isn't this a cross-platform issue?
All platforms
OS: Mac System 8.5 → All
Hardware: Macintosh → All
WFM on Win2K, fails on Mac.  Not sure what makes it break.
Target Milestone: --- → mozilla0.9.7
spam: over to File Handling.
Component: XP Apps → File Handling
Attached patch fix (obsolete) — Splinter Review
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).
Why not just include dialogOverlay.js using a <script> tag?
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.
Yes. I've tried to convince danm that this would be a good thing. Mac OS has:

enum {
    kWindowNoPosition           = 0x0000,
    kWindowDefaultPosition      = 0x0000,                       /* used by 
    kWindowCenterMainScreen     = 0x280A,
    kWindowAlertPositionMainScreen = 0x300A,
    kWindowStaggerMainScreen    = 0x380A,
    kWindowCenterParentWindow   = 0xA80A,
    kWindowAlertPositionParentWindow = 0xB00A,
    kWindowStaggerParentWindow  = 0xB80A,
    kWindowCenterParentWindowScreen = 0x680A,
    kWindowAlertPositionParentWindowScreen = 0x700A,
    kWindowStaggerParentWindowScreen = 0x780A
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.
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.
Attachment #59784 - Attachment is obsolete: true
Whiteboard: needs review/super-review
I still need some reviews on this.  Please?
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 on attachment 59802 [details] [diff] [review]
updated patch, uses <script> instead of overlay
Attachment #59802 - Flags: superreview+
Whiteboard: needs review/super-review
Closed: 23 years ago
Resolution: --- → FIXED
verified fixed using 2002.01.29.1x comm verif bits on linux rh7.2, win2k and mac
Summary: Downloading 'Set Default' dialog should be centered on the parent dialog → Downloading 'Advanced' dialog should be centered on the parent dialog
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.