Closed Bug 14513 Opened 21 years ago Closed 20 years ago

window size does not persist

Categories

(Core :: XUL, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: cmaximus, Assigned: pavlov)

References

Details

(Keywords: platform-parity, Whiteboard: [PDT+])

*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.
QA Contact: ckritzer → claudius
Status: NEW → ASSIGNED
Target Milestone: M11
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
Blocks: 23773
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.
Blocks: 17799
Blocks: 23915
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.
Whiteboard: [PDT-]
Putting on PDT- radar
Priority: P1 → P3
Target Milestone: M15
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
Keywords: pp
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.
Keywords: beta1
Summary: [PP][DOGFOOD] window size does not persist → window size does not persist
Whiteboard: [PDT-]
*** Bug 25923 has been marked as a duplicate of this bug. ***
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
checked in fix
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Blocks: 26981
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 ago20 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.