14513 - window size does not persist

Status: VERIFIED FIXED

(Core :: XUL, defect, P3)

Description

[Claudius Gayle]

*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.

Comment 1

[Chris Waterson]

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

Comment 2

[Stuart Parmenter]

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

Comment 3

[Chris Waterson]

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

Comment 4

[Chris Waterson]

bulldozer to M12

Comment 5

[Chris Waterson]

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.

Comment 6

[Stuart Parmenter]

i will hunt you down

Comment 7

[Syd Logan]

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.

Comment 8

[Chris Waterson]

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

Comment 9

[Dan M]

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.

Comment 10

[Claudius Gayle]

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

Comment 11

[leger]

Putting on PDT- radar

Comment 12

[Peter Trudelle]

targetting M15, p3

Comment 13

[leger]

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

Comment 14

[Akkana Peck]

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.

Comment 15

[sairuh (rarely reading bugmail)]

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

Comment 16

[leger]

Putting on PDT+ radar for beta1.

Comment 17

[Stuart Parmenter]

checked in fix

Comment 18

[Akkana Peck]

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.

Comment 19

[Akkana Peck]

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.

Comment 20

[Claudius Gayle]

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

Comment 21

[Claudius Gayle]

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

Comment 22

[Akkana Peck]

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.)

Comment 23

[Akkana Peck]

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

Comment 24

[Claudius Gayle]

marking VERIFIED based on my and akkana's previous comments

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/43ee066b90c4
[fenix] FNX-14513 ⁃ For https://github.com/mozilla-mobile/fenix/issues/12862: Use concept-menu in library (https://github.com/mozilla-mobile/fenix/pull/13332)