67079 - Window position not restored properly on Mozilla startup.

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[Stephen Moehle]

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.

Comment 1

[Jun MUTO]

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

[Stephen Moehle]

Fixed summary spelling.

Comment 3

[Stephen Moehle]

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

Comment 4

[Fabian Guisset]

Reassigning to [e-mail]

Comment 5

[Dan M]

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.

Comment 6

[Dan M]

Attachment: stagger on all extant windows of the same type

Comment 7

[David Hyatt]

Reassigning to danm so he can claim glory for the fix. 

Comment 8

[Dan M]

patch is in

Comment 9

[Brendan Eich [:brendan]]

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

Comment 10

[Dan M]

Attachment: Fix Brendan's string issues. I claim poorly copied code's to blame.

Comment 11

[Brendan Eich [:brendan]]

My tardy review led danm to re-patch, and I say that mod can go in with an
sr=[e-mail], as if it had been made before the first patch went in.

/be

Comment 12

[Dan M]

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

Comment 13

[timeless]

yeah yeah, i'll work on it this month.