From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.8+) Gecko/20020220 BuildID: 2002022003 There's a problem with browser window size when you maximize/fullscreen/restore. Reproducible: Always Steps to Reproduce: 1) set theme to Modern (haven't tried Classic) 2) set the window size to something other than maximized; note the size and position of the window 3) maximize browser window 4) enter fullscreen mode 5) exit fullscreen mode Actual Results: a) the window is at the Maximized _size_ ...BUT b) the window is actually in the 'Restored' state. This leads to confusion about how to get the correctly sized/positioned 'Restored' window back, since I never (thought I) changed it. Expected Results: I believe that the 'Restore' button in fullscreen mode should 'restore' to whatever state the window was in _before_ fullscreen mode took effect, not necessarily the Windows 'Restored' mode. fix: No, you don't need to edit localstore.rdf :-} Make sure the window is in the 'Restored' state and then move it so you can see the borders and then resize it.

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

-> hewitt

I also see this on win98se, same build, confirming.

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+, topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any questions or feedback about this to adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.

This bug is also present in Classic theme.

This effectively breaks Restore functionality for anyone who uses full screen mode. Nominating for nsbeta1. Also clearing Target Milestone to trigger reevaluation since this was targeted at 1.0 before it was auto-moved.

resolving as invalid, current behavior is as intended.

I think you are confusing this bug with bug 126678. Reopening. Is it really by design that if you maximize the browser window, enter full screen, and then exit full screen, the window does *not* go back to maximized state, rather, it goes to *restored* state but positions itself as if it was maximized?

I noticed that before it goes to maximized size, it first goes to restored position with the correct dimensions, then it resizes to make it appear maximized. The resizing changes the default restored state, thus we must manually readjust the browser size. I suggest that in the meantime, if this bug isn't fixed soon, we should just remove the resizing and leave it restored. It's easier to maximize than to manually resize to the desired restore size everytime. It's like replacing a bug with a lesser bug. :)

No, not confusing with any other bug, just not reading carefully enough while trying to reproduce. Renominating, but doubt we can get to this, so adding helpwanted keyword.

nsbeta1+ per Nav triage team, ->1.0, adt3

2002033108 OS/2 800 X 600 Once I hit F11 whilst fullscreen, the only way I can get restored back is to resize manually, both Classic and Modern. I'd change the severity to major if I had the power, and it is definitely not windoze only, which also I cannot change.

Where's the code that resizes the window when entering/exiting fullscreen mode? It looks like it's restoring to the proper size, but then being resized the the max window size. If the code looks anything like I hope it does, it should be pretty straight-forward to fix.

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

Platform/OS to All/All based on comment 12. Is this bug really going to make it for 1.0?

Another symptom of this problem, as reported in bug 133239, is that Alt-Spacebar | Restore from fullscreen mode does not work right. Alt-Spacebar | Restore should exit fullscreen mode and return the window to its previous position.

Andrew: you're seeing bug 127014, "restore" command (from taskbar or alt+space) doesn't disabled in full screen mode.

Okay, I'll try to fix it. OS/2 is on the PC.

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

Mass moving nsbeta1+/adt3 bugs assigned to Navigator team engineers out to target milestone 1.0.1. Please confine your attentions to driving down our list of TM 1.0 bugs for beta. Better to help, debug, or test one of them than fix one of these.

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.

This should be pretty straight forward, right? Current behavior is 1) Restore 2) Resize Just change this to 1) Restore 2) Maximize. I know you eventually want to get rid of step 1 (go directly from Full Screen to Maximized while remembering restore coordinates) but this should be good enough for now, IMO.

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

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

Taking

Keeps the sizemode of window when turned full screen on and restores the sizemode if it's maxzimized when turned full screen off.

Comment on attachment 92069 [details] [diff] [review] patch for Windows I think it might be simpler than this - the problem is that the chrome and resize is happening in the same order both times, but one should be the reverse of the other; my preference is to hide the OS chrome before resizing the window.

no, this is not exactly the problem. we can descibe what we did when toggle full screen here: 1) normal size 2) maximized window 3) turned on full screen, recorded mOriginalPos and mOriginalSize, e.g. (0, 0), (800, 600), 4) turned off full screen, restore window size/postion by using mOriginalPos/mOriginalSize, then the window is maximize-sized but not maximized, because we didn't remember the original sizemode at all.

Is the patch from Comment #27 ready for a review/super review or not? It sounds like it fixes the bug. Another annoying behavior caused by this bug is when middle-clicking on a link after the window was restored from fullscreen mode and did not clicked the maximize icon , the new window that is created is shifted a little toward the lower-right corner.

Yes, it's ready for r= (see there is "review" in the keywords list), but it's still incompleted, because the patch only fixed the problem on Windows. I'll try to fix the *nix part in a near future.

kyle, see also the patch I'm working on over on bug 176640. I don't think it's difficult to merge the changes, but my patch puts all of the fullscreen logic in nsBaseWidget.

Comment on attachment 92069 [details] [diff] [review] patch for Windows bryner, your fix for bug 176640 does fix this problem on Windows, but seems it's still on Linux.

=> bryner for the gtk part fix

I don't see this problem on Redhat 7.3 (though fullscreen is not really "full screen" as that only seems to work now under Metacity).

note that fullscreen does work for me with sawfish2 & recent trunk (gtk1)

This bug also seems to affect the browser's saved window state after closing. This is best seen on a dual display machine (or possibly only). 1) Open browser and place in secondary display. 2) Maximize browser window. 3) Enter Fullscreen mode. 4) Exit Fullscreen mode (Notice the window is maximized as expected). 5) Close the browser. 6) Re-open the browser. Notice that the browser is not maximized as it should be and was before being closed--instead it is in a restored state but taking up the entire window, sans the taskbar. I imagine this bug is widespread. I have tested and verified this behavior in both of the following environments: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030729 Mozilla Firebird/0.6.1

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

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

We only need a fix for Linux to get this one closed.

Not going to hold 1.7alpha for this. We'd consider taking a reviewed patch if someone comes up with a fix

after maximize (F11), the navigation bar which should be minimized become maximize and there is another minimized navigation bar ......

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 Still happening on XP, with one thing to note: If you follow the instructions in the original stage, the window will be maximized. When you restore the window, the window is now larger (at least length-wise) than the maximized window. I have a 1280 x 1024 screen resolution with a 2-line taskbar at the bottom, leading me to believe that the "restored" window is actually 1280x1024.

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

This is still present in XP with Firefox Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050919 Firefox/1.4 ID:2005091906 It would be really nice if this got fixed in time for 1.5 as it's a pretty visible polish bug that has been an annoyance forever. I'm seeing this using the following steps: 1. Window is in restored state to begin, at a smaller size than the screen 2. Maximize 3. Go into fullscreen 4. Come out of fullscreen 5. Firefox is now in maximized mode, as expected 6. If you try and go back to restore, window size and position has been lost and it is stretched to the max screen size. Nominated blocking1.8b5.

seems to wfm on winxp in ff 1.5.0.4

Skips call to MakeFullScreenInternal, gdk_window_fullscreen and gdk_window_unfullscreen handles this on its own.

Maybe if that GTK_CHECK_VERSION call fails (can it ever really?) we should call MakeFullScreenInternal(aFullScreen) after HideWindowChrome. The best way to achieve that is probably to just have the #else path call nsBaseWidget::MakeFullScreen. And if we're doing *that*, we should remove nsBaseWidget::MakeFullScreenInternal and just put it inline into nsBaseWidget::MakeFullScreen.

Restores call to nsBaseWidget::MakeFullScreen for old gtk versions. MakeFullScreenInternal integrated into MakeFullScreen. Removed duplicate call to HideWindowChrome.

Comment on attachment 295296 [details] [diff] [review] fixes the maximize/fullscreen/restore cycle on newer gtk cool. This a simple fix, we should land it for FF3. Thanks!!!

Checking in widget/src/gtk2/nsWindow.cpp; /cvsroot/mozilla/widget/src/gtk2/nsWindow.cpp,v <-- nsWindow.cpp new revision: 1.247; previous revision: 1.246 done Checking in widget/src/xpwidgets/nsBaseWidget.cpp; /cvsroot/mozilla/widget/src/xpwidgets/nsBaseWidget.cpp,v <-- nsBaseWidget.cpp new revision: 1.168; previous revision: 1.167 done Checking in widget/src/xpwidgets/nsBaseWidget.h; /cvsroot/mozilla/widget/src/xpwidgets/nsBaseWidget.h,v <-- nsBaseWidget.h new revision: 1.93; previous revision: 1.92 done