149332 - Mozilla doesn't save its windows position when closed.

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[John Slevin]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.0.0+) Gecko/20020604
BuildID:    2002060410

Open Mozilla, position window at the top left of the screen.  Close Mozilla. 
Open Mozilla and it opens to a default screen loacation and not the top left
where it was closed.  It saves the window size but not the position.

Reproducible: Always
Steps to Reproduce:
1.Open Mozilla, position window at the top left of the screen.
2.Close Mozilla.
3.Open Mozilla and it opens to a default screen loacation and not the top left
where it was closed.

Actual Results:  It saves the window size but not the position.

Expected Results:  Should open at the top left of the screen where it was closed.

Comment 1

[Matthias Versen [:Matti]]

wfm on win2k and 20020603..

-> XP APPS

Comment 2

[Jeroen Oortwijn]

Confirmed on BeOS Mozilla build 2002060909.

But for me it always opens at the top left of the screen even when I closed
Mozilla in the top right.

Comment 3

[Sergei Dolgov]

bug reason found. NS_MOVE event wasn't ever sent to XUL, so functions from
nsXULWindow.cpp always supposed screenX and screenY being 0, and  saved those
values in localstore.rdf. hough, if you change values in this file manually,
Mozilla started on expected position.

Problem fixed at my home machine, patch in preparation.

Comment 4

[Sergei Dolgov]

libwidget

Comment 5

[Sergei Dolgov]

Attachment: patch

implements and overrides NS_IMETHOD GetScreenBounds(),
implements and overrides FrameMoved(),
creates local method call ONMOVE

Comment 6

[Paul]

from patch: http://bugzilla.mozilla.org/attachment.cgi?id=87249&action=view

+        //determine if the window position actually changed 
+       if (origin.x == lastpoint.x && origin.x == lastpoint.x) { 
+               //it didn't - don't bother 

lastpoint is undefined, and therefor will not compile.

Also, could you clean up the indentation.  According to the header, it should be
tab-indented.

Comment 7

[Sergei Dolgov]

Attachment: patch

+ TitleBar.height correction added for first start (uninitialized
localstore.rdf)
diff for nsWindow.cpp included (lastpoint)
Dunno about identation - mostly i just copied existinf functions (like
GetBound()) with its' style

Comment 8

[Paul]

Attachment: Updated patch to go against recent nsWindow changes

I updated the patch to go against changes I recently checked into the tree.
I also cleaned up nsWindow.h a bit.

Also, your change for offsetting the window, to take into account for the
title bar does not seem to work.
It moves the rect.y value down, but then resets the entire rect to mBounds. 
Though, even if I move the change to rect.y after the set to mBounds, it still
does not work.

On the other hand, we could probably just removed this, as it will only happen
once on someone's machine, which I'm ok with, but, it would be nice to have
it working properly.

Also, is the title bar 2* the height of a scroll bar?  Or is it just close
enough?

Comment 9

[Sergei Dolgov]

yeah Paul, i need investigate things more. Btw, i noticed, that OffsetBy(10,30)
to BRects in Bwindows constructor  in nsWindow.cpp hasn't effect. We are
depending here, it seems, on general Mozilla code outside widget module. So
maybe Move() functions should be also reworked. And you right, even without this
titlebar correction, once positioned properly, all components stay on its
positions. Fortunately, in BeOS we can move anything by draggin borders, not
only TitleBar.
Though, i had last week huge Mozilla hacking and coding session without those
focus, popups, and Net+Bookmarks issues. And now also investigating possibility
to open dropped files (Gregor's request, big 89020). So this problem may stay
untouched for some time 

Comment 10

[Paul]

Attachment: updated above, to remove offset "fix"

Same patch from above, just removed the one line for trying to offset window
to take into account for the title bar.

Sergei, if you could review this, and give it your r=, I will check it in.
I'll then create a new bug, for the window pos on inital startup.

Comment 11

[Sergei Dolgov]

r=[e-mail]

Comment 12

[Paul]

the last patch has been checked in