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

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.

This is definitely a duplicate.

Probably yet, yet, yet, yet, yet, yet another localstore.rdf bug. Sigh. Nick, can you still reproduce this problem under 0.9.6?

This isn't a localstore bug. (Put down the hammer; not everything is a nail). -> pinkerton, Mac OSX

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. :-(

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

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

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.

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.

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

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

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

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

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.

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

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

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

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.

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 on attachment 68450 [details] [diff] [review] unzoom window when sized with the mouse sr=ben@netscape.com

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

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.

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.

I just checked this back in. marking fixed again.

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.