The Select User Profile should be centered in the screen

VERIFIED WORKSFORME

Status

P3
normal
VERIFIED WORKSFORME
19 years ago
14 years ago

People

(Reporter: bugzilla, Assigned: danm.moz)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
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

Updated

19 years ago
Assignee: selmer → rgoodger

Comment 1

19 years ago
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.
Status: NEW → ASSIGNED
this can be done. I've achieved this in my profile manager updates. will check
in fix for this with the rest of it...
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 4

19 years ago
builds 20000113 on all platforms
(Reporter)

Comment 5

19 years ago
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

Updated

19 years ago
Component: Profile Manager → Profile Manager BackEnd

Comment 6

19 years ago
Moving all Profile Manager bugs to new Profile Manager Backend component.
Profile Manager component to be deleted.
(Reporter)

Updated

19 years ago
Status: VERIFIED → REOPENED
(Reporter)

Comment 7

19 years ago
Please read my notes from 2000-01-15

Updated

19 years ago
Resolution: FIXED → ---

Comment 8

19 years ago
Clearing FIXED resolution due to reopen.

Updated

19 years ago
Component: Profile Manager BackEnd → Profile Manager FrontEnd

Comment 9

19 years ago
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. ***

Comment 12

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

Comment 13

19 years ago
m15

Target Milestone: 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. ***

Comment 16

19 years ago
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 :)

Assignee: ben → danm
Status: REOPENED → NEW

Comment 18

19 years ago
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.
(Assignee)

Comment 19

19 years ago
bite me
Depends on: 26645
*** Bug 27200 has been marked as a duplicate of this bug. ***

Comment 21

19 years ago
Reproduced on MacOS build 2000021608. Setting platforms and OSes to All.
OS: Windows 98 → All
Hardware: PC → All
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M15 → M16

Comment 22

19 years ago
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);                                       
}                                                                               

Comment 23

19 years ago
Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2
Target Milestone: M16 → M17

Comment 24

19 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → WORKSFORME

Comment 25

19 years ago
build for 20000428 on all platforms
Status: RESOLVED → VERIFIED
(Assignee)

Comment 26

19 years ago
  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.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.