Closed Bug 14513 Opened 21 years ago Closed 20 years ago
window size does not persist
*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
Assignee: waterson → pavlov
Status: ASSIGNED → NEW
Target Milestone: M13
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
Summary: [PP] Linux Manage Bookmarks window size does not persist → [PP] window size does not persist
Priority: P3 → P1
Summary: [PP] window size does not persist → [PP][DOGFOOD] window size does not persist
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.
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.
Component: XUL → XP Toolkit/Widgets: XUL
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.
Summary: [PP][DOGFOOD] window size does not persist → window size does not persist
*** Bug 25923 has been marked as a duplicate of this bug. ***
Putting on PDT+ radar for beta1.
checked in fix
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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!
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
marking VERIFIED based on my and akkana's previous comments
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: claudius → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.