Closed
Bug 67079
Opened 24 years ago
Closed 24 years ago
Window position not restored properly on Mozilla startup.
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla0.9
People
(Reporter: smoehle, Assigned: danm.moz)
Details
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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.')
Reporter | ||
Comment 2•24 years ago
|
||
Fixed summary spelling.
Summary: Window postion not restored properly on Mozilla startup. → Window position not restored properly on Mozilla startup.
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
Comment 7•24 years ago
|
||
Reassigning to danm so he can claim glory for the fix.
Assignee: ben → danm
patch is in
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla0.9
Comment 9•24 years ago
|
||
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
Assignee | ||
Comment 10•24 years ago
|
||
Comment 11•24 years ago
|
||
My tardy review led danm to re-patch, and I say that mod can go in with an
sr=brendan@mozilla.org, as if it had been made before the first patch went in.
/be
Assignee | ||
Comment 12•24 years ago
|
||
nsXULWindow.cpp has returned to its status as a model of string usage.
Comment 13•24 years ago
|
||
yeah yeah, i'll work on it this month.
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•