In the last day or two, Mozilla no longer restores the browser window to the position it was in when Mozilla was last shutdown. My screen resolution is 1024x768. I keep the Mozilla browser window with a width of 690 at the right edge of the screen. When I shutdown and restart Mozilla, the browser windows is placed against the left edge of the screen. I have noticed that in localstore.rdf, if I set screenX to 312 (see below) and start Mozilla, the browser window will be placed all the way to the right. If I now shutdown Mozilla at this point without repositioning the browser window, screenX becomes 333. On restart, the browser window is all the way to the left again, and screenX is 0. There must be something wrong with the math since a screenX value of 312 should not have placed the browser window all the way against the right edge of the screen in the first place since 312 + 690 (the window width) is 1002, not 1024 which is my screen resolution. Something is off by 22 pixels. <RDF:Description about="chrome://navigator/content/navigator.xul#main-window"> <sizemode>normal</sizemode> <screenX>312</screenX> <screenY>0</screenY> <width>690</width> <height>736</height> </RDF:Description> Tested with Mozilla 2001013004 on NT4.
It seems both screenX and screenY are added 22 pixels whenever mozilla starts up or new window opens. This also affects preferences window. This bug can be reproduced on Win95 (Build ID 2001013004). (BTW 'postion' in Summary would be misspelling of 'position.')
Fixed summary spelling.
Summary: Window postion not restored properly on Mozilla startup. → Window position not restored properly on Mozilla startup.
I suspect that this bug is caused by the fix for bug 25455.
Reassigning to email@example.com
Assignee: asa → ben
Yes, the first window is being offset from its stored position as if there were already a window there. (That additionally causes it to stick to the top/left edge if it was too far to the bottom/right). Definitely bug 25455 bustage. I guess we failed to look closely enough when verifying the patch. Bad on us. Patch to fix attached. Note this has a double loop looking through all extant windows of the same type. Kind of bothersome. It also doesn't quite work on all multiple- monitor situations.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reassigning to danm so he can claim glory for the fix.
Assignee: ben → danm
patch is in
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla0.9
Don't write NS_ConvertASCIItoUCS2("windowtype"), the better way is NS_LITERAL_STRING("windowtype") because it avoids a copy on Windows and (some day soon) Linux. + PRUnichar* wtype = windowType.ToNewUnicode(); Why malloc and copy a duplicate that's freed after the loop? windowtype.get() should be good enough, I hope. /be
Created attachment 24062 [details] [diff] [review] Fix Brendan's string issues. I claim poorly copied code's to blame.
My tardy review led danm to re-patch, and I say that mod can go in with an firstname.lastname@example.org, as if it had been made before the first patch went in. /be
nsXULWindow.cpp has returned to its status as a model of string usage.
yeah yeah, i'll work on it this month.
You need to log in before you can comment on or make changes to this bug.