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.
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.
Summary: Window positions are not saved between sessions on Mac OS X → Window positions are not always saved between sessions on Mac OS X
Or it may be related to bug 86955.
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.
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.
adam, i've seen that in macos9 builds. ben has that bug somewhere on his list, and it's quite annoying.
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.
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?
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.
*** This bug has been marked as a duplicate of 88563 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
Target Milestone: Future → ---
You need to log in before you can comment on or make changes to this bug.