107937 - New windows maximized

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Nick Kocharhook]

It hasn't always been this way, but every time time I open a window now 
it's maximized. It'll show up normally sized, and then it will be maximized. 
I'm not sure what caused the change.

Mozilla ID: 2001101516

Comment 1

[Nick Kocharhook]

I figured out why this was happening. Apparently I had hit the maximize widget
on one of the windows at some point. So every new window was also maximized.

Hitting the maximize widget twice fixed the problem, but it's still a bug.
Maximization should last only for the duration of the window maximized, and
should not apply to other windows.

Comment 2

[Greg K.]

This is definitely a duplicate.

Comment 3

[Greg K.]

Probably yet, yet, yet, yet, yet, yet another localstore.rdf bug. Sigh.

Nick, can you still reproduce this problem under 0.9.6?

Comment 4

[John Morrison]

This isn't a localstore bug. (Put down the hammer; not everything is a nail).

-> pinkerton, Mac OSX

Comment 5

[Nick Kocharhook]

FWIW, I can still reproduce this bug in 0.9.6. Once a window is maximized, even
if it's resized to be smaller after maximization, every new window will be
maximized until the window is de-maximized again with the maximize control.

This is a pretty serious bug, IMHO. I'm a techie, and I lived with the VERY
annoying symptoms of this bug for over a week, unable to figure out why it was
happening. When it got to be too much, I debugged it and solved the problem, but
I'd be willing to bet most folks would just live with it -- or stop using
Mozilla. :-(

Comment 6

[Mike Pinkerton (not reading bugmail)]

whatever you want to call it, the bug is that the wrong state gets written out
to the localstore so it thinks forever on that windows should be maximized. this
bug has been around for a long time, on os9 as well. it's not OSX-specific.

--> danm

Comment 7

[sairuh (rarely reading bugmail)]

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

Comment 8

[Paul Baker]

Thank god I found this bug report!!! Yes hitting maximize a couple of times did
fix this for me. I have been living with this problem for a week or two now and
it has been driving me out of my **** mind let me tell you.

Comment 9

[Mike Pinkerton (not reading bugmail)]

if nothing else, we need to release note this. I disagree with the "future"
milestone as well.

danm, we get probably a user a week in the mac newsgroup grumbling about this
and not knowing how to fix it. It's a serious end-user issue. I'm pulling this
back out of Future to get it re-triaged. I'll stand in your cube and take my
spankings next time I'm in mtnview for it, but it's the right thing to do.

Comment 10

[Steve Dagley]

Adding to the OS X really need to have fixed meta bug.

Comment 11

[Nick Kocharhook]

I am confident that this is a duplicate of bug 103032. The behaviors are
identical. Even the workaround is the same.

Comment 12

[John Morrison]

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

Comment 13

[Adam Masri]

Platform: PowerBook G3/300/192Mb/48Gb, MacOS X 10.1.2
Fizzilla build: 2002013008

Hello,

My bug 123685 just got duped against this one, so I'll stick my notes here. This
is definitely a localstore.rdf problem. I have a localstore.rdf file that will
cause this problem to occur. I was having this problem, so I moved my
localstore.rdf to another folder, deleted XUL FastLoad File, and the problem
disappeared. Then I quit Fizzilla and:

1) Moved the working localstore.rdf file to my desktop

2) Deleted XUL FastLoad File

3) Moved the broken localstore.rdf back into my Mozilla folder

On launching Fizzilla, the problem returned. If I changed window location and
size, closed the Nav window & reopened or quit Fizzilla and relaunched, the
window was full size again. Then I:

1) Trashed XUL FastLoad & localstore

2) Moved the working localstore back into my Mozilla folder

The problem disappeared.

I'm a little sketchy posting this file as an attachment, since it may have some
personal stuff in it. But I wouldn't mind giving it to Steve if he's working on
this. :)

- Adam

Comment 14

[Dan M]

Adam: we don't need your entire localstore.rdf file; just the piece that causes
the problem. You can edit out great chunks of it and relaunch, if you're careful
not to break the XML syntax.

If it's like every other similar bug I've seen, there's a single bookmark
somewhere in the <RDF:Seq about="nc:urlbar-history"> section that contains an
unprintable character, probably in the [0x01-0x1A] range. That would make this
one of the standard "corrupt localstore.rdf" bugs, more or less a duplicate of
bug 88563 and dependent on bug 99236. That last one's really just a stopgap;
better to stop the file from going corrupt in the first place, but we haven't
been able to figure out why that happens yet.

Comment 15

[John Morrison]

Actually, this one isn't one of the 'corrupt localstore.rdf' bugs; this is 
particular to OS/X isn't it? 

[And, as I just noted now on bug 99236, a not-well-formed localstore.rdf file 
is now handled "gracefully" by the RDF XML datasource. A corrupt file will lead 
to default settings when the browser comes up, and the corrupt file is 
overwritten by the datasource).

Comment 16

[Adam Masri]

Attachment: My broken localstore.rdf

Ok, I edited down my localstore.rdf. I took out a lot of URLs & stuff that I
didn't think would be necessary for testing. I tested it, and it causes the
window to open full size every time, even if you resize it.

Please note that this started occuring after I visited
www.hawkcommunications.com, which forces your Moz window to full screen size.
You will notice two references to that site in the file. I'm not an expert on
reading these files, so I leave that to you.

Last, if you come across anything proprietary, or porn related, please let me
know so I can remove it. Hey, we're all friends here, right? ;)

- Adam

Comment 17

[Adam Masri]

Attachment: A second copy, uploaded as text/plain

I'm not sure if that upload went ok. Looks a little loopy. I told Bugzilla to
"auto-detect." I'm uploading a second copy, just in case that one's broken.

- Adam

Comment 18

[Simon Fraser [no longer active]]

The culprit is this "maximized" attribute:

  <RDF:Description about="chrome://navigator/content/navigator.xul#main-window"
                   screenX="0"
                   sizemode="maximized"
                   screenY="0"
                   height="698"
                   width="897" />

We know it gets there, we just don't know how (always). Sounds like
www.hawkcommunications.com is a good test case.

Comment 19

[Dan M]

Attachment: unzoom window when sized with the mouse

Oh right. I forgot what this bug was about. The problem as I understand it is
that if you zoom a window and then resize it, we don't note that and think the
window is still zoomed.
  Just an oversight. This patch takes care of that, I think without upsetting
all the other interconnected XP things going on. It resets the zoomed state
when the window is sized by mouse, persists the zoomed state when the size
changes, and removes a redundant method. (State persistence when the window
size is changed by script is already taken care of elsewhere.) There are more
obvious places to make these changes, but they proved more troublesome. I think
this is good.

Comment 20

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 68450 [details] [diff] [review]
unzoom window when sized with the mouse

sr=[e-mail]

Comment 21

[jag (Peter Annema)]

Comment on attachment 68450 [details] [diff] [review]
unzoom window when sized with the mouse

>Index: mozilla/xpfe/appshell/src/nsWebShellWindow.h
>===================================================================
>RCS file: /cvsroot/mozilla/xpfe/appshell/src/nsWebShellWindow.h,v
>retrieving revision 1.122
>diff -w -u -4 -r1.122 nsWebShellWindow.h
>--- mozilla/xpfe/appshell/src/nsWebShellWindow.h	5 Feb 2002 12:41:47 -0000	1.122
>+++ mozilla/xpfe/appshell/src/nsWebShellWindow.h	8 Feb 2002 00:22:47 -0000
>@@ -202,13 +201,13 @@
> 
>   nsIDOMNode * contextMenuTest;
> 
>   nsCOMPtr<nsITimer>      mSPTimer;
>-  PRBool                  mSPTimerSize, mSPTimerPosition;
>+  PRBool                  mSPTimerSize, mSPTimerPosition,mSPTimerMode;

Nit: space after comma.

r=jag

Comment 22

[Dan M]

  thanks!
  Some question remains of whether I've actually solved the bug by addressing
the problem I did in the patch. So of course reopen it if I haven't, but do
please give a good explanation because as far as I can tell, it's fixed.

Comment 23

[Dawn Endico]

Reopening

Backed out this change because it seemed like a likely cause of a
startup time regression (bug 124570). Backing this out didn't seem
to make a difference in Ts. It should be ok to check back in but
I'll wait till someone gets a handle on the problem.

Comment 24

[Dawn Endico]

I just checked this back in. marking fixed again.

Comment 25

[Dawn Endico]

mcafee turned off mathml on comet and comet's Ts went down by 10ms. Since
comet gained 30ms on friday we should continue looking for the other 20ms.