Overview Description: This bug is the offspring of Bug 15775, it may actually be a dupe, but I wanted to split it out. Width, height, screenx, screeny are supposed to be updated when a window is moved or resized. On the Mac this is not happening unless/until a new window is created. Steps to Reproduce: 1) Open localstore.rdf (in Profile directory) and note the values of screenx et al. 2) Launch Browser. Move and resize the window. I then surfed a page just for kicks. 3) Quit the browser and reexamine localstore.rdf --Alternatively(instead of step 3), you could just restart the browser and see that the window has reverted to the same position as when you started it the previous time. Actual Results: The localstore.rdf file does not seem to have been updated (with the relevant changes- I did not check mod dates/times). Upon restart the browser window has reverted to the old size/ position. Expected Results: screenx et al, should be written out immediately after a move/resize event. The browser would then 'remember' is last position and size upon restart. Build Date & Platform Bug Found: Mac OS 9 Build 2000011810 Additional Builds and Platforms Tested On: Mac OS 8.5 NOT tested due to build troubles. WinNT 2000011808 does NOT show this bug. RH 6 2000011808 screenx does not persist ever - some other bug?

(Marking "worksforme" as a kind of temporary way to reassign this to Claudius.) And then there's this: I'm not seeing this at all. For one thing, don't expect to see these window parameters flushed immediately to the localstore file. They may be properly updated but only held in memory for a time. However, I'm not seeing the described behaviour with a Mac build from yesterday. I'm seeing instead that any time a window is moved and closed, its size is remembered correctly, but its position is remembered as something like twice the actual (x,y) values plus the width of the window border. Or something like that. Confirm?

Okay the behavior has definitely changed from the comm opt build I noted yesterday and the one I'm testing with now, 2000011910. I imagine your pull from yesterday caught those changes as well. There's no denying the previous behavior though. It was easy to notice b/c the window never reappeared in the same place as you left it. Moving on, you seem to have captured today's behavior well. What I see is that the incorrect values are being written out for screen position while the correct values are written for size. They are off by what seems to be some regular factor but I didn't crunch the numbers. So the behavior wherein the values weren't being updated seems to have gone away(this bug). Now we are faced with incorrect values being written, different bug? one caveat is my tests yesterday were on OS 9, whereas today's were with Mac OS 8.5.1. I'll be double-checking to make sure that isn't the difference.

In spite of (offline) discussions to to contrary, it turns out that I can still reproduce this with 20000120 opt comm bits. Moreover, as I had hoped against yesterday I can only repro this on my OS 9 machine. The only other significant difference between my two machines is the OS 8.5.1 machine has gobs of memory whereas the other has barely enough to run the OS, seamonkey, and Nav 4.71. To recap, if i launch the build, move and resize the window, and quit. When i restart the window is the original size and near (diff'nt bug) the original position. Whereas if I launch the build, move and resize the window, open a new window, and then quit. When I restart the window is the smae size and near the smae place where I left it. reopening and...

...immediately clearing the WFM resolution

Putting on beta1 radar.

Putting on PDT+ radar for beta1.

Window positions are always assumed stored in local coordinates. But in the middle of a window move, and that's when the position is stored if persistent, it's temporarily in global coordinates. Adjusted so it will always be local, even then.

VERIFIED fixed with the 2000012812 build on Mac OS 9.