55081 - Browser window size is not saved after closing w/cmd-W

Status: RESOLVED WORKSFORME

(Core :: XUL, defect, P3)

Description

[Simon Fraser [no longer active]]

In my current branch commercial build, the size of the browser window is not
being saved between sessions. This indicates a serious memory leak somewhere.

Comment 1

[Simon Fraser [no longer active]]

Nominate for rtm, because this
a) breaks the saving of windows size entirely
b) indicates a serious memory leak (since size saving should happen in some
teardown code that is never being hit now).

Comment 2

[Chris Waterson]

We should verify that nsXULDocument is leaking:

1. Create a file called ENVIRONMENT in the app's folder. Add the following line
to this file:

   XPCOM_MEM_BLOAT_LOG=bloat.log

2. Start the browser; shut down.

3. Open the file "bloat.log" (analagous to the ones produced on Linux tinderbox)
and verify that nsXULDocument is leaking.

Comment 3

[Chris Waterson]

Attachment: bloat log, showing that simon is right

Comment 4

[Chris Waterson]

Hrm, we're not leaking nsXULDocument objects, but we're leaking plenty of other 
stuff that's not leaking on Win32 or Linux. The nsXULDocument object is the thing 
that is supposed to persist window dimensions, IIRC.

Comment 5

[Mike Pinkerton (not reading bugmail)]

could this somehow be related to nisheeth's bug about calling
nsPresShell::EndLoad() on the wrong presShell when surfing from page to page?
That would indicate a leak to me...

http://bugzilla.mozilla.org/show_bug.cgi?id=53501

Comment 6

[Peter Trudelle]

this is about browser window size not being saved. rtm-/future.
Leak should be a separate bug.  When filing it, please be specific about leak
frequency & magnitude.

Comment 7

[sairuh (rarely reading bugmail)]

*** Bug 60311 has been marked as a duplicate of this bug. ***

Comment 8

[Adam]

If bug 60311 is indeed a duplicate of this, then the problem is caused by
closing a window via Command+W (at least the "Browser window size is not saved"
part of it). I argue that this is a big problem, regardless of a memory leak, as
you have to avoid using the Command+W keyboard shortcut (which has
single-handedly ruined my entire Mozilla M18/Netscape 6.00 experience).

Comment 9

[Steve Dagley]

Browser window position made the CNet downgrade review and is an obvious polish 
flaw which makes it a candidate for the next bus.  Adding Dogfood keyword

Comment 10

[selmer (gone)]

converting from dogfood to catfood.  Updated summary to include cmd-W
requirement (please correct if that wasn't right.)

If the leak still exists, please move that to another bug.  This bug is about
the size not being saved, regardless of the cause.

Comment 11

[Avi Rappoport]

I'm getting this problem intermittently in 0.9.3 on Mac OS 9.1.  Sometimes it
works and new windows take the old window size, mostly they just show up as big
as the main screen.  VERY annoying.

Comment 12

[Greg K.]

*** Bug 95585 has been marked as a duplicate of this bug. ***

Comment 13

[Greg K.]

Correction: I opened a new window, which was fullscreen. I then clicked the maximize 
button again (to minimize), and it resumed a normal window size, and now all new 
windows open in the normal size.

Comment 14

[Dan M]

  I don't see this happening with today's trunk build. The nsXULDocument leak has 
been fixed (it's been ten months; that's good...) and generally window size/state 
persistence is accurate for me.
  The only misbehaviour I'm seeing is that after zooming to maximized state and 
quitting (regardless of how that's done; Cmd-W Cmd-Q; mouse; speed of keystrokes; 
Mozilla or Netscape build; nothing seems to matter) the window's "normal state" 
size is too large. So after quitting and restarting, the window is properly 
maximized but when zoomed back to normal it's too large.
  (And there are two different maximized sizes: see bug 80431). (And the "too 
large normal" size looks suspiciously like one of those two zoomed sizes.) That's 
all I'm seeing. Can anyone provide specifics? (Exact steps, problem, data in 
localstore.rdf, whatever? Try again with a fresh localstore.rdf? (There is 
another known bug that seems to happen with a corrupt localstore; see bug 
88563)).

Comment 15

[Brad Tiffany]

OK, here is the problem I see (Greg alludes to this).  Maximize your browser
window.  Now resize it to something smaller.  Close it.  Open a new window. 
Notice that this window is maximized.  Try shrinking it again, closing it, and
opening another window.  Dammit, why are these windows always so big!  File bug
in bugzilla.  Bug remains unconfirmed because you forgot the first step
(maximizing the window) and no one can reproduce it.

The problem is that the mac has no notion of a persisted "maximized" state and
it is easy for users to get all of their new windows stuck in this state without
realizing it (I'll bet there are 5-10 "windows too big on mac" bugs floating
around bugzilla--mailnews as well as browser--because of this.  I'll try to mark
dups).

The fix might reasonably be one of the following:

1.  Don't have a notion of persisted maximized state at all on the mac.
2.  Mark a window as no longer maximized once a user resizes it.
3.  Make the mac zoom box behave like a mac zoom box (bug 53506).

Btw, this issue might be confused with localstore.rdf corruption since trashing
even a valid localstore.rdf file will unstick the maximized state.  As a test,
try having a single browser window open, clicking the zoom box once (to
un-maximize the window), and closing the window.  That fixes the problem I'm seeing.

Comment 16

[Ben]

I've encountered this same issue (it seems) on a Mandrake 9.1 setup.  Any ideas?

Comment 17

[Ben]

I've encountered this same issue (it seems) in Mozilla 1.3 on a Mandrake 9.1
setup.  Any ideas?

Comment 18

[Joey Richards]

I am seeing a similar problem with Mozilla 1.3 under Mandrake 9.0 (KDE upgraded
to 3.1, though same problem was present in the stock KDE).  In this case, no
method of closing the browser causes the size to be saved.  Furthermore, the
browser window always starts up maximized, regardless of the state when it was
closed.  Hitting the "normal size" button causes the window to go to something
less than full screen, but that size is fixed.

Comment 19

[Dan M]

This bug is so fixed by now. The leak is long gone and window state persistence
is live and healthy. It's working for me on OSX and RedHat. You guys probably
have corrupt localstore.rdf files. This has generally been the cause of stuck
windows. (See bug 96221 comment 13 and bug 88563 comment 15.) At the time of
those bugs, localstore corruption was creeping in through bookmarks. That seems
fixed (see bug 99235) but it could have returned in some new form.

Ben (comment 17) noticed the window came unstuck when he deleted his
localstore.rdf but got stuck again immediately. This doesn't really sound like
localstore is the root problem. Can someone seeing this bug verify a corrupt
localstore? Does the problem go away when you delete localstore? Does it stay
gone? Is there perhaps something else in your profile causing the problem?

I'm looking for something amiss on your systems since the problem doesn't appear
to be general. Feel free to open a new bug (or reopen this one if you find a big
leak as described in comment 2*, but I'm not seeing that). It'd be helpful if
someone could pin down the problem a little, since we can't see it from here.

(* - note comment 2 gives obsolete Macintosh instructions. On all supported
platforms today, instead of creating a file set the environment variable
XPCOM_MEM_LEAK_LOG=leak.log.)

Comment 20

[Dan M]

Others are seeing this problem too. You want bug 198874.