User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2a) Gecko/20020909 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2a) Gecko/20020909 Whenever I launch Mozilla for the second time after I delete the profile and made a new one, clicking the green resize button in the upper left corner makes the current window disappear completely. It seems it gets resized to just a window of 1 by 1 pixel, as I still see a small white dot in the upper left corner, but somethimes it's also a line of approx. 1 by 10 pixels. Closing the window with ctrl-w and making a new one doesn't help, only deleting the profile and creating a new one makes the window become visisble again. This affects both Mozilla 1.0 and 1.1. They used to work liek expected under Mac OS X 10.1.*, but it's broken now under 10.2 Reproducible: Always Steps to Reproduce: 1. Create a new profile, launch and exit Mozilla and then launch it again. 2. Click the green resize button in the upper left corner of the window. 3. Actual Results: The current window disappeared, it seems it got resized to a 1x1 window. Expected Results: Maximize the current window.

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

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

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

Bug 167663, bug 166519, bug 167545, and bug 166963 all seem to be the same problem (window shrinks to an extremely small size under OS X 10.2). Arbitrarily marking the others as duplicates of this one.

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

I can reproduce this bug, though I have experienced several variations of this bug, the window becomes tiny as described or it moves up by a centimeter, so it can't be dragged anymore, because the title bar is below the menu bar, or the buttons in the title bar dissappear (and reappear when you pass with the mouse over them). The fastest way to fix this, is to keep a pristine copy of 'localstore.rdf' from a freshly created user profile folder handy, and replace the corrupted version of this file in your user folder with it. Restart Mozilla, that's it.

Confirming based on dupes (I have not got a Mac myself, so cannot reproduce this bug). Guessing on correct component. -> XP Apps

I have posted a corrupted localstore.rdf file at: http://www.ivuk.ethz.ch/staff/haenchen/localstore.rdf Simply deleting it, and letting Mozilla recreating it, is the fastest way to fix the problem.

From that posted localstore.rdf, I think that this line is fairly obviously the one that's causing the trouble: <RDF:Description about="chrome://navigator/content/navigator.xul#main-window" screenX="16" screenY="22" width="1" height="1" sizemode="normal" /> This problem isn't caused by the localstore.rdf file directly, of course. The issue is why clicking the maximise/resize/green button causes the window to resize to 1x1 pixels in the first place.

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

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

It happens to me, too. Not necessarly when I make a new profile, but it also happened when I closed all the windows, and then opened a new one and maximized it.

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

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

FWIW, I fixed it by renaming ~/Library/Mozilla/ApplicationRegistry aside. Aside from the corruption issue, when Mozilla starts up or creates a new window, it should check for sane values and reset before using them. If the drag region isn't accessible, or if the window is sized too tall for the resize region to be brought on-screen, the recorded window size should be replaced with sane values.

Possible dup of bug 164579?

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

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

From dup bug 164579: "This only occurs if Mozilla was closed while in a maximized state, i.e., if you start with a normal size window you can click + all you want and it works fine. But if you quit while maximized, the next time you start Mozilla and click the + button your browser will disappear." Not sure if this is exactly the same bug, but I'm sure it will turn out to have the same cause.

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

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

I agree that this is critical, but it's not dataloss or regression. It doesn't cause any dataloss (just (critical) loss of function), and it's not a regression, since it has never worked under 10.2, AFAICS.

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

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

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

The bug (or some variant) seems to continue in build Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021008 Ken

Bug 173389 may be a dup of this, but reports the symptom after *minimizing* the window, not maximizing it as here.

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

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

Nav triage: this seems to be a fairly bad regression on osx. Traction here would be nice...

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

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

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

Nav triage team: nsbeta1+/adt2

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

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

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

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

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

Two cents- just another person who is affected by this bug. First tried 1.1, then 1.2a, now 1.2b on OS X 10.2.1. Tried the delete profile then create new profile gag and it works. Next time I will try the localstore.rdf edit to fix the 1 pixel by 1 pixel corruption. It's the only severe bug I have found with the browser so far.

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

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

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

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

this one confused me for a long while, and is bound to block an average new user permanently.

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

in the localstore.rdf file, it seems starting at line 55 the file is changed to this (or similar) but the width & height are "1" which is the MAIN PROBLEM: <RDF:Description about="chrome://navigator/content/navigator.xul#main-window" screenX="40" screenY="40" width="1" height="1" sizemode="normal" /> should be, minimally: <RDF:Description about="chrome://navigator/content/navigator.xul#main-window" screenX="40" screenY="40" width="50" height="50" sizemode="normal" />

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

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

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

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

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

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

i see this with Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1) Gecko/20020826. clicking Maximize causes the window to become a one-pixel-wide line, actually. somehow, just by clicking and dragging it in various ways, i've been able to get it back to a useable state. unfortunately, sometimes, it will Maximize itself such that the Title Bar is offscreen. Moz doesn't seem to have enough window options to correct that (i.e., there's no way to drag it back onscreen). no profile was deleted. in fact, this seemed to have nothing to do with profile with the exception that i guess this was the first time i had ever tried Maximize under Moz 1.1 and Jaguar.

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

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

This is pretty severe regression (e.g. most users will not know how to get themselves out of this bad state), that should be looked at (hopefully resolved), prior to shipping 1.0.2 final.

topembed nominating, I think this occurs in embedding clients (Chimera) as well

actually, i've never seen this behavior with Chimera 0.5 or 0.6 under either 10.1.x or 10.2.x...

-> danm for a look

Heh. Thanks. I've tried to reproduce this in the past; no success. Can anyone with a debugging environment see this problem?

per bucklands request: commercial, 1.0.2 branch build (2002-11-12) I was unable to produce this problem in Mozilla 1.0 based branch builds.

The original reporter says it occurs on 1.0 ... "This affects both Mozilla 1.0 and 1.1. They used to work liek expected under Mac OS X 10.1.*, but it's broken now under 10.2" And, has been reporduced on my PowerBook G4 and on paw's machine. Sadly, I don not have a debug environment, but paw, might.

Discussed in team meeting. There is currently no fix for this bug, it is not always reproducible, and we have no other outstanding bugs that would require a spin. We have decided to release note this bug for Blackbird. ccing Jatin to get on release note radar

I'm running OSX 10.1.2, and I can't reproduce this. This report and the first dozen duplicates all mention 10.2. We can reliably reproduce this on a machine here running 10.2.1, but we can't reproduce this on a machine running 10.2.2. First reaction: what the *%#? Second reaction: it seems to be a bug in Jaguar that was fixed in 10.2.2. Recommend users upgrade. Folks seeing this bug, do you concur? Is it a 10.2 <= X <= 10.2.1 problem? Still, it'd be nice to have a workaround for those who haven't upgraded.

I doubt this is an OS bug; it's much more likely to be at our end. Maybe it has to do with what sites you've visited (js-resized windows) or something. How about a bullet-proofing fix that pin the height/width values read from localstore.rdf to a minimum size?

I'm running MacOS X 10.2.2 and am able to reproduce the problem.

Comment 65 is incorrect; this bug is still present when running under 10.2.2. Just a little trickier to reproduce. (However it truly doesn't happen under 10.1.2.) Simon: I see we don't sanity check the window size. Heh. Yeah we should probably do that. Note bug 74940 is about implementing a minimum window size; that's sort of related. However a sanity check on the persistent window size coming from localstore is only a partial fix: it'll help if the user quits out of frustration and restarts, but it won't prevent the initial problem. Guaranteed steps to reproduce (not all necessary but this always seems to work): 1) Launch into Profile Manager, create fresh new profile. 2) Continue to Navigator, zoom the browser window. 3) Quit. 4) Relaunch Mozilla. The browser window is maximized. 5) Unmaximize. Window goes to 1x1. 6) Quit in frustration. Between steps 3 and 4 the window size in localstore.rdf is still correct. (Though after step 6 the window size in localstore is 1x1.) So in step 5 a reasonable unmaximized window size has been pulled from localstore but this doesn't stop the window-dot from happening.

strangely, after upgrading to 10.2.2, i was unable to reproduce the problem with Moz 1.1 without doing anything explicitly to profile information. i don't know if this is useful information, at this point, but i figured i'd provide it, anyway.

I can confirm 100% reproducibility (with no special steps, just the Maximise button) in OSX 10.2. Ken

Had it occur last night w/ OS X 10.2.2, Mozilla 1.2b. Happened w/ both the browser and the mail/news window.

If this bug needs to be in the Blackbird release notes, please add a description and any workaround to Bugscape 20320.

danm, drivers would really like a fix (even a bandaid) for 1.2 which is rsn. Would a sanity check on localstore, as mentioned in comment 68, help 1.2 final users?

Turns out we're not very good about keeping the window's userstate up to date when we size or move a window. Previous OSes seem to have done this for us, so we could be sloppy. OSX 1.2 seems also to do this, usually, but this bug describes a situation where it doesn't. The userstate remains at its default 1x1 so when the window is zoomed back to normal size, the OS happily sizes the window to 1x1. From then on the window's persistent size is also 1x1 and you're thoroughly hosed. This patch explicitly updates the userstate when we size or move. I'm unclear on some details; maybe some better Mac weenie can make corrections. For instance, when to use GetWindowPortBounds/LocalToGlobal and when to use GetWindowBounds(... kWindowGlobalPortRgn ...) ? If that latter one is Carbon-only, it seems to be misused already. There's still some funky business happening with userstate. I don't much like UserStateForResize() (though I think I wrote that) and the standardstate calculation is made too often. But presumably that stuff's all working and I wanted to leave it alone since this patch may go into Mozilla 1.2. I've been playing with this patch for ten minutes or so. It seems generally good though I have noticed one minor sizing glitch that's way better than 1x1. Because of the patch's potential 1.2-ness, more eyes and fingers on it would be a good thing.

I've reconsidered the above patch's desire to change the StandardState. The description in the comment above still applies.

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

+ StPortSetter ourPort(mWindowPtr); + ::GetWindowPortBounds(mWindowPtr, &portBounds); + ::LocalToGlobal((Point *) &portBounds.top); + ::LocalToGlobal((Point *) &portBounds.bottom); + ::SetWindowUserState(mWindowPtr, &portBounds); You should probably just use GetWindowBounds(... kWindowGlobalPortRgn ...) here. It's a shortcut for what you're doing and is supported on 8.5 and up (non-carbon). I haven't tried the patch at all, but it looks reasonable.

Comment on attachment 106498 [details] [diff] [review] keep userstate updated when window is moved or sized r=pink

danm: who do you have lined up to sr= the patch?

Comment on attachment 106498 [details] [diff] [review] keep userstate updated when window is moved or sized I concur with pink. I think our standard state/user state management is probably whacked in general, but if this bandaid works, go for it.

Comment on attachment 106498 [details] [diff] [review] keep userstate updated when window is moved or sized sr=dveditz for the nsMacWindow changes Do you need to do the same thing for the ::SizeWindow call in nsMacMessagePump()?

Discussed in team meeting. Plussing for adt. We are going to try to get this in. Jatin, please watch this bug re release note. danm can you get drivers approval for the 1.0 branch asap?

Comment on attachment 106498 [details] [diff] [review] keep userstate updated when window is moved or sized a=chofmann for 1.0.2

dveditz: hmmm. Good call. However in my ad-hoc testing I haven't noticed any problems that the additional change you suggest would imply. There's another inGrow case in nsMacEventHandler that already resets the UserState, so I believe the mouse sizing case has already been taken care of. I can't check this any time soon because I'm building my tree and it's a Mac. The current patch will fix the 1x1 bug as it stands because the code that restores persistent window size goes through nsMacWindow::Resize (which the patch patches), so the window gets a not-1x1 userstate during initialization. However the mouse-sizing case you mention wants consideration.

The docs say that the OS updates the window user state when the user resizes the window (by dragging the grow box around), so the change in nsMacMessagePump should not be necessary.

a=asa for checking to the 1.2 branch (on behalf of drivers). Thanks for the fix!

i noticed that this was checked into the moz1.0.2 branch, so i tested this a little bit with another build (2002.11.18.13-1.0 commercial, OS 10.2.2). new profiles seem to work fine (tested using the steps in comment 68). however, using an older profile, this is still a problem. that is, the windows remained tiny and unusable. was the fix supposed to take care of this bug for existing profiles, or only new profiles?

Mrking topembed+ as part of topembed triage.

I'm using branch 2002111813-1.0 and no longer see the problem. I tried it on 2 profiles. However, both profiles are relatively new, since I just received my Mac a few weeks ago.

Based on the steps in comment 68, I can't reproduce using the 2002-11-18-13 1.0 build either. Tested under 10.2.2. Going to try with a variety of older profiles I have made.

This fix only prevents people from getting into a bad state. If you use a corrupted profile (or localstore.rdf actually), then you can never get out of this state. So the behavior described by Sarah with an old profile is probably correct.

I was unable to reproduce this with every profile on my machine, 6 old and three new using Mac branch build 2002-11-18-03-1.0 (OS 10.2)

Adding keyword fixed1.0.2 since the fix has been checked in.

I couldn't reproduce with two week old profiles using the 2002-11-18-04 NB. In addition, I created new profiles with NS 7.0 RTM and could not reproduce issue with these profiles either. Tested under 10.2.2.

Yes, the last patch just prevents the problem from happening. It doesn't correct the problem once you're already in that state. This patch would do that. I wouldn't want to do it on the trunk, though. It's a little bit of a hack. And it's also cross-platform, so more than just the Mac builds would need to be re-spun. (Without this fix, you need to either never have been in this state, or hack or delete your localstore.rdf file.) What's the verdict then? This one, too?

Sorry, I mean I couldn't reproduce in the 2002-11-18-13 build with older profiles.

Do we know when this problem started? If Mozilla 1.1 or 1.0.x (or Netscape 7) had the problem and people got in this bad state then we should try to fix it for them. If the problem is limited to recent nightly builds then it doesn't concern me as much.

The problem began with OSX 1.2. Run M6 on 1.2 and it'll happen. (I expect.) Or possibly it doesn't happen under pre-Carbon builds. Anyway it's old. I've asked for reviewers to hit the second patch.

What is this OSX 1.2 of which you speak? Do you mean 10.2?

Comment on attachment 106733 [details] [diff] [review] no persistent windows smaller than 100x100 Why is this a hack you wouldn't want on the trunk? Even on the trunk there would seem to be no real reason for a user to have saved a 1x1 window size, this kind of sanity check might save us from other similar problems.

Simon: Uh... yeah. Apparently I thought 10.2 just didn't have enough digits in it. OK any time in the past that you saw me utter the somewhat confusing phrase "OSX 1.2" just splice out some digits to arrive at what I meant. dveditz: The hardwired minimum window size urks me. Still, I suppose "hack" is overstrong. It's a reasonable hardwired minimum size and it would be acceptable I think if softwired minimum sizing like, say, in bug 74940, were able to override it.

Comment on attachment 106733 [details] [diff] [review] no persistent windows smaller than 100x100 a=asa for checkin to the 1.2 branch (on behalf of drivers).

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

even though is an OS X-only issue, i sanity-checked the window controls on mac 9.1 (2002.11.19.05-1.0), and they're fine.

Thanks for checking that, sairuh. Both patches (prevent the problem from happening, fix the problem in case you were hosed by an earlier build) are checked in to the trunk and to the 1.2 branch. Only the patch which prevents the problem from happening in the first place has been checked in to the 1.0 branch. Whew! Popular bug. I believe the fix is everywhere it wants to be. Closing.

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

Verified on the branch using MacOS X build 20021118. Since there is going to be a more extensive fix for the trunk which will be different from the Branch, I am going to reopen the bug for the trunk.

Since this bug has been fixed on the 1.2 branch, but will remain open, removing the dependency from the 1.2 tracking bug.

Paul: what more extensive trunk fix is expected? I closed the bug because I had done everything I intended to do to fix it. The only additional applicable work I can think of would be to un-hardwire the minimum window size implemented to correct profiles broken by previous versions of Mozilla. But that's covered in bug 74940. I'm all done here unless you know of something else.

Sorry, I didn't realize that all the work on the trunk was completed. I will reset the bug as Resolved/Fixed. This now needs to be verified on the trunk

Our team performed # automation testing (dhtml, dom-core, dom-html, client-side JS, dom-events, dom-views, forms submission, secure forms submission) # Selective manual testing that could have any relation to window open/close/resize/move in areas like HTML, XML and XLink . # Javascript Events testing. We did not find any regression. Everything went fine.

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

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

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

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

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

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

I've found a couple more dupes of this bug. I'd be glad to deal with them (and various other defunct bugs I've seen) if someone will give me dupe-marking privileges.

for bugzilla privs, you want to talk to Gerv (Gervase Markham). See the following URL: http://www.mozilla.org/bugs/

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

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

Marking Verified per comment 111, and also WorksForMe using FizzillaMach/2003-05-20-08-trunk.

i'm seeing this again on: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030826 steps to reproduce: 1. maximize browser window 2. resize to approximately the same size 3. maximize browser window if you've got tabs open, only the content pane (not the browser chrome) will turn gray or white. if you don't, both chrome and content pane turn gray or white.

bug 150057 has screenshots of what this looks like using "Classic" theme. comment 123 describes behaviour with "Modern" theme. i've also checked this against the most recent nightly, and the problem persists.

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

I am also seeing this problem - MacOSX 10.2.6 with the Mozilla 1.5b release - if you maximise the window using the green "button" in the window titlebar, and then change applications and switch back to Mozilla and click the Maximise button again, various parts of the screen go white. I will attach a screen dump so you can see what I mean. As you move the mouse over the regions of the screen, they begin to redraw correctly.

If you drag the resize control in the bottom right hand corner of the window, the window will redraw correctly.

Nightly build of Sept 30,2003. Mozilla 1.6a, eMac, System 10.1.5. Closed window while it was maximized. Opened new window, (which came up maximized) switched to another app and back, clicked Maximize again. The toolbar area was blank. Repeated with a page from my hard drive - on 2nd click, it was blank except for an image it had and a blank space at the bottom (had colored background). Running the mouse over the toolbar caused it to redraw piece by piece, but blank pieces didn't redraw. (I've seen similar behavior in IE 5) Resizing the window with the resize corner fixed the display. Repeatedly clicking Maximize had little effect - it didn't even toggle the Maximum size anymore.

Reassigning since I'm helpless on Mac issues these days. Sorry, Simon. Slightly more grief: it's an old bug re-opened instead of a new one, so you can ignore everything before comment 123.

Could you describe what this patch is doing?

Comment on attachment 134293 [details] [diff] [review] Invalidate Window even if position doesn't actually change By tracing through the code, I figured out that when this bug materialized the code was stopping on the return statement shown near the patch area. When things work, it gets farther on. The lower code eventually calls the Invalidate method which is what redraws the window. I added this piece into the spot where the separation was occurring.

It would be nice to know why this invalidate is required, i.e. the underlying cause for the bug. seems that this patch is really a band-aid.

I don't disagree that the patch is probably more of a band-aid. All the code seems to assume that when any of these events are called and no change is made to the position of the window, the window doesn't need anything else done to it. When the button works, the Invalidate event is actually called something like 15 times. When it doesn't, the method is not called at all. I believe the code could use a complete re-write that would probably fix many other outstanding issues on the platform. That said, I'm not sure I'm capable of performing such a rewrite and think it better to put in a simple fix and work on a re-write afterwards than to let such a bug stay any longer than is necessary.

This bug actually starts at comment 123 and my guess is that it's not the same bug at all as originally reported.

Actually, morphing this bug would be painful. Let's take this discussion to but 167663, if that is indeed the same problem, or create a new bug. Thanks.

oops, that's bug 161249

Comment on attachment 134293 [details] [diff] [review] Invalidate Window even if position doesn't actually change As I suspected, this patch is just a band-aid. I'll look into the issue some more.

Resolution for the remaining issue is in bug 161249.