Right noe the "Select User Profile" appears in the top left corner of the screen. It should appear in the center of the screen, like in Netscape 4.7. Using build 20000106

This depends on being able to calculate the position from javascript. There used to be a bug about being able to get the screen's X and Y coordinates, not sure what happened to it. If it's still open, then this one depends on that one.

this can be done. I've achieved this in my profile manager updates. will check in fix for this with the rest of it...

fix checked in...

builds 20000113 on all platforms

Yesterday it was centered just fine, but with todays build 2000011415 it's suddenly located more near the buttom, right corner and not centered! The dos box says: Move window by 456,356.5

Moving all Profile Manager bugs to new Profile Manager Backend component. Profile Manager component to be deleted.

Please read my notes from 2000-01-15

Clearing FIXED resolution due to reopen.

Moving to Profile Manager FrontEnd component. (not changing owners yet)

this bug IS fixed. there's *another* bug in the positioning of the window, by gum. this worked for me the day I checked it in then quickly broke the following day.

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

m14. ben if this is fixed, please mark it so.

m15

when I discover which of the (supposedly numerous) window problems this depends on, I'll mark it so ;)

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

Same problem exists for the select-user dialog of single signon. To get to that dialog, do the following: 1. Visit a site that has a login form (e.g., bugsplat) 2. Fill in the login and submit it. 3. Anser yes to the question about saving password 4. Return to the login form. It will be prefilled. 5. Change the username to something else (it need not even be valid) 6. Submit it and again save it 7. Again return to the login form At this point you are presented with a select-user dialog. And that dialog is not centered. Can this bug report serve to cover both cases or would you prefer that I open a separate bug for the single-signon select user?

steve, look in dialogOverlay.js and you'll find some functions at the bottom, one is: centerWindowOnScreen(); Make sure you call that (and include dialogOverlay.js) from the function associated with the onload handler in your dialog. call that and the window should be centered on screen. The reason this bug exists is because the screen positioning that this function calls is functioning improperly. As such, I don't really own it. Reassigning to danm, who will either know how to fix it, or have a better idea of who owns it :)

Thanks, that worked and I just checked it in for the select-user single-signon dialog. So ignore all references to the single signon problem in this report.

bite me

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

Reproduced on MacOS build 2000021608. Setting platforms and OSes to All.

I've added some dump code to centerWindowOnScreen (as shown at the end) and this is what I got: startPage:: newProfile1_1 got a request centerWindowOnScreen() avail: 800x600 outer: 1x1 inner: 1x1 Move window by 399.5,299.5 I don't know why exactly outerWidth and outerHeight are 1, their values are correct in navigator.js: function BrowserClose(), which stores them in localstore.rdf. Apparently somewhere between <html:iframe src="about:blank" style="width: 400px; height: 200px;" name="content" id="content" scrolling="none" flex="1"/> in createProfileWizard.xul and the window referred to in centerWindowOnScreen the outerWidth en outerHeight don't get set (correctly). ----- function centerWindowOnScreen() { dump("avail: "+screen.availWidth+"x"+screen.availHeight+"\n"); dump("outer: "+window.outerWidth+"x"+window.outerHeight+"\n"); dump("inner: "+window.innerWidth+"x"+window.innerHeight+"\n"); var xOffset = screen.availWidth/2 - window.outerWidth/2; var yOffset = screen.availHeight/2 - window.outerHeight/2; //(opener.outerHeight *2)/10; xOffset = ( xOffset > 0 ) ? xOffset : 0; yOffset = ( yOffset > 0 ) ? yOffset : 0; dump( "Move window by " + xOffset + ","+yOffset+"\n"); window.moveTo( xOffset, yOffset); }

Mass-moving all M16 non-feature bugs to M17, which we still consider to be part of beta2

This seems to be fixed for a while now. The later builds just automatically create a default profile, so to test it start mozilla with -ProfileManager. It seems some C code was checked in which centers the profile manager (and all others with their centered flag set), obsoleting (or rather overriding) the javascript code (which can be removed from createProfileWizard.js:Startup(...)). That code still doesn't work though. I'll see if I can find an appropriate bug or otherwise create one. Marking WFM.

build for 20000428 on all platforms

The problem with centering dialogs in JS is probably* a problem with sizing to content. At the time the onload handler runs (which is when our windows that have JS centering code did their thing) the window hasn't yet been sized. I can't make an argument that the onload JS should necessarily run after the window has been sized (someone may *want* access at that earlier time), so I'm not prepared to call that a bug. It's just the order things happen in. So you can't make calculations using a window's size in the onload handler in an intrinsically sized window. You could work around this in JS by putting your centering code on a timer, though that would certainly flash. Our workaround was to put the centering code in just the right spot in C. You can get to it from JavaScript by specifying a flag in the window.open call. * -- I say "probably" because I haven't verified this for certain. But that would probably be a waste of time. This has to be what's happening.