*Summary The size of the manage bookmarks window does not persist after you resize, close, and reopen it. *Builds This bug is LINUX only and was reproduced on a Linux RH6.0 machine with the 1999092108 builds. It was NOT reproducible with the same days builds on MacOS8.5 or WinNTsp4. *To Repro Open the bookmarks window (Bookmarks|Manage Bookmarks). Change the size of the window. Close the window. Open it again, note size. *Actual behavior The change in size is not remembered and the bookmarks window opens at its default size each time. *Expected behavior After resize and closing the window the next time you open it, it should open at the size you left it.

pav: any idea if GTK is ignoring window size info?

nope, and i have no idea why this is happening. \

ok, could be we don't call document destructor. will investigate.

bulldozer to M12

pav buddy, this really -is- your bug. Here's the deal. In navigator.js, the "onunload" handler gets the (x,y,width,height) of the window off of the JS 'window' object. (See http://lxr.mozilla.org/mozilla/source/xpfe/browser/content/resources/navigator. js#557) It seems like the widget system is never telling the DOM when these values change for X only. I put a 'dump()' call in there, and no matter -what- I resize the window to, it always comes up as (x,y,width,height) of (0,0,640,480). I even played around with stuff, hacking the default window size to something different: no matter what, the DOM always thinks that the window size is the same as the original size that it came up with. talk to a windows or mac weenie (probably danm) to see how to get widget to push the right attributes onto the DOM object. I cleared the TFV. triage as you see appropriate.

i will hunt you down

IM is failing to display the 1st message because we are prematurely getting a call to our onunload handler. Marking p1 and dogfood, because our bug in socpus is dogfood.

amusil was going to file a separate bug for the "onunload" handler to me.

Answering waterson's comments above: all platforms have their own similar but different methods for getting and setting the JS size values, but they don't actually go through the DOM. A short exam suggests to me that the problem here is, a window's size is fetched for JavaScript from nsWindow's mBounds member variable. That variable is updated when a window is sized. But the (first) window that gets the size message is the webshell window, while the window that fields the accessor request is the webshellwindow window just above the webshell window. They don't talk to each other, so the reported size never changes.

are this bug and bug 15775 related? I'm the only name in common to the two so I thought I'd pipe up.

Putting on PDT- radar

targetting M15, p3

BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL. XUL component will be deleted.

Moving keywords from summary to keywords field, requesting consideration for beta1. This is a major annoyance on Linux which has long since been fixed on the other platforms.

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

Putting on PDT+ radar for beta1.

checked in fix

Reopening -- now all my browser windows start up at 100x100, regardless of what I sized them to the last time I ran mozilla. Removing localstore.rdf doesn't help.

If I start up with an argument -- e.g. "mozilla http://home.netscape.com" -- then the window size from last time is remembered. If I just run mozilla with no arguments, I get the 100x100 window.

i wonder if this is a debug only problem? My size is persisting (although not my position) with the 2000020809 linux RH6 builds

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

You're right! I don't see this in a release build, only in my debug build (which was a fresh tree pulled at about 10:45am). I wonder if the profile manager is somehow screwing things up? (But the profile manager comes up even when I run with an argument, and it's a lot bigger than 100x100.)

It looks like I pulled at the wrong time. I just updated, and the problem seems to have gone away. Yahoo!

marking VERIFIED based on my and akkana's previous comments