Last Comment Bug 524258 - Fullscreen fix for 1.9.1 & 1.9.2
: Fullscreen fix for 1.9.1 & 1.9.2
Status: RESOLVED FIXED
:
Product: Core Graveyard
Classification: Graveyard
Component: Widget: OS/2 (show other bugs)
: 1.9.2 Branch
: x86 OS/2
: -- normal (vote)
: ---
Assigned To: Rich Walsh
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-23 21:11 PDT by Rich Walsh
Modified: 2014-12-09 11:27 PST (History)
4 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---
beta2-fixed
.6-fixed


Attachments
fix for 1.9.1 and 1.9.2 (2.09 KB, patch)
2009-10-23 21:12 PDT, Rich Walsh
mozilla: review+
Details | Diff | Review
fix for 1.9.2 (2.09 KB, patch)
2009-10-23 21:13 PDT, Rich Walsh
no flags Details | Diff | Review

Description Rich Walsh 2009-10-23 21:11:28 PDT
Bug 267609 & other sources report several issues with fullscreen mode.

The first involves this sequence:
- maximize a browser window
- put it in fullscreen (aka "kiosk") mode
- minimize it, then restore it

In v1.9.1, the problem occurs when you exit fullscreen mode.  The frame & its controls are restored but the window completely fills the screen.  The maximize/restore button has no effect;  the window has to be resized manually.

In v1.9.2 & 1.9.3, the window remains in fullscreen mode (no frame or frame controls) but it's only the size it was before being maximized (i.e. it doesn't fill the screen).  When you exit fullscreen, it then has the same problem as 1.9.1.

Minimizing a fullscreen window produces two minor issues:  the minimized icon appears on top of other windows, rather than below them; and, if the window was previously maximized, you can't doubleclick on the icon to restore it - you must select "Restore" from its menu.

The attached patches for 1.9.1 & 1.9.2 avoid these issues by making fullscreen & maximized modes mutually exclusive.  If a window is maximized, it's restored before entering fullscreen mode.  This approach requires far less code & contorted logic than would be needed to make the two modes compatible.

Note:  the two patches are identical except for the line numbers.  A similar patch for the trunk that involves more extensive changes will be attached to Bug 522896.
Comment 1 Rich Walsh 2009-10-23 21:12:41 PDT
Created attachment 408178 [details] [diff] [review]
fix for 1.9.1 and 1.9.2
Comment 2 Rich Walsh 2009-10-23 21:13:28 PDT
Created attachment 408179 [details] [diff] [review]
fix for 1.9.2
Comment 3 Peter Weilbacher 2009-11-04 14:43:07 PST
Comment on attachment 408178 [details] [diff] [review]
fix for 1.9.1 and 1.9.2

>+  if (WinQueryWindowULong(hFrame, QWL_STYLE) & WS_MAXIMIZED) {
>+    WinSetWindowPos(hFrame, 0, 0, 0, 0, 0, SWP_RESTORE | SWP_NOREDRAW);

This patch needed these two hFrame replace with hwdnFrame, but otherwise it's OK. I'll fix that on checkin.
Comment 4 Peter Weilbacher 2009-11-04 14:53:33 PST
Comment on attachment 408179 [details] [diff] [review]
fix for 1.9.2

Same problem here. (I meant hwndFrame, of course.)
Comment 5 Peter Weilbacher 2009-11-04 15:08:32 PST
Pushed to both branches (trunk will follow in bug 522896, hopefully soon):
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/7ea1df77c185
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/0533271ae9a2

Note You need to log in before you can comment on or make changes to this bug.