101579 - Window positions are not always saved between sessions on Mac OS X

Status: RESOLVED DUPLICATE of bug 88563

(Core :: XUL, defect)

Description

[Simon Fraser [no longer active]]

We are not correctly saving window positions between sessions on Mac OS X. I
have to reposition my browser windows every time, and all dialogs come up
top-left the first time you show them in a session.

Comment 1

[Simon Fraser [no longer active]]

Hrmm, this seems somewhat sporadic. I've definately seen windows positions not 
get saved, but it works sometimes. Maybe it depends whether I quit with Command-Q 
(and thus hit bug 92750) or not.

Comment 2

[Warner Young]

Or it may be related to bug 86955.

Comment 3

[Dan M]

bug 86955 now happens only if you size a window from the top or left margins, and 
then only the position is lost, and I'm pretty sure only on Windows. In my 
experience window persistence is working fine everywhere else, but I don't speak 
for OS X. Must be something OS X specific. Sounds like localstore.rdf isn't being 
saved between sessions. !%!#$ that bug seems to pop up in some form every couple 
of months.

Comment 4

[Adam]

The behavior I see on Mac OS X is that the window will always open in the
position of the "lowest" open window from the last session. Meaning that if you
only browse with one window, it should be in the same spot the next time. If you
simultaneously open up 5 different browser windows in one session, the next time
you launch Mozilla, the window should be drawn where the 5th tiled window was.
Pretty annoying. May or may not be related, though.

Comment 5

[Mike Pinkerton (not reading bugmail)]

adam, i've seen that in macos9 builds. ben has that bug somewhere on his list,
and it's quite annoying.

Comment 6

[Adam]

Indeed. It's the only noticeable and 100% reproduceable problem I've had with
window position on Mac OS X, though (other than the fact that no app seems to be
able to create a window flush with the left side of the screen in 10.1 - they're
always 5px or so to the right). I'm mainly using 0.9.4 builds, though, so there
might be a different problem with trunk builds.

Comment 7

[Mike Pinkerton (not reading bugmail)]

where are we with this bug (besides it being futured w/out any RFC)? I tried it
with my 1/16 build and it seems to remember the window positions for me.

We did just have a different bug where RDF wouldn't persist any settings on a
volume with a '/' in it. Could that be the problem here?

I think this bug is WFM or Fixed, anyone care to comment?

Comment 8

[Dan M]

  Heh. RFC before Future. Heh heh.
  IMO (embracing the use of TLAs here) Bugzilla could use another field or
milestone or something. I've always treated Future to be the equivalent of
Gulag, but I'm under instruction to prove that I've considered my bugs (that is,
move them out of Untargeted) and I've realized from experience that any
milestone more than a couple away is just kidding. So now Future is a mixture of
gulag and "no really I do intend to look at this someday." Unfortunate.

  This bug probably falls in between even those two categories. As far as I know
window positioning persistence is working, with a couple of exceptions I've
noted in other bugs that I don't want to go looking for right now. All window
persistence problems that I've seen in the last several months have, after much
discussion and trial, repeated afresh in every instance, turned out to be bug
88563, which is kind of the same as bug 99236. This one can probably be closed.

Comment 9

[Dan M]

*** This bug has been marked as a duplicate of 88563 ***