Window position not restored properly on Mozilla startup.

RESOLVED FIXED in mozilla0.9


18 years ago
14 years ago


(Reporter: Stephen Moehle, Assigned: Dan M)


Windows NT

Firefox Tracking Flags

(Not tracked)



(2 attachments)



18 years ago
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">

Tested with Mozilla 2001013004 on NT4.

Comment 1

18 years ago
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.')

Comment 2

18 years ago
Fixed summary spelling.
Summary: Window postion not restored properly on Mozilla startup. → Window position not restored properly on Mozilla startup.

Comment 3

18 years ago
I suspect that this bug is caused by the fix for bug 25455.

Comment 4

18 years ago
Reassigning to
Assignee: asa → ben

Comment 5

18 years ago
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.
Ever confirmed: true

Comment 6

18 years ago
Created attachment 23897 [details] [diff] [review]
stagger on all extant windows of the same type

Comment 7

18 years ago
Reassigning to danm so he can claim glory for the fix. 
Assignee: ben → danm

Comment 8

18 years ago
patch is in
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.


Comment 10

18 years ago
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, as if it had been made before the first patch went in.


Comment 12

18 years ago
nsXULWindow.cpp has returned to its status as a model of string usage.

Comment 13

18 years ago
yeah yeah, i'll work on it this month.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.