As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact
Last Comment Bug 524258 - Fullscreen fix for 1.9.1 & 1.9.2
: Fullscreen fix for 1.9.1 & 1.9.2
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
Depends on:
  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: ---

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 | Splinter Review
fix for 1.9.2 (2.09 KB, patch)
2009-10-23 21:13 PDT, Rich Walsh
no flags Details | Diff | Splinter Review

Description User image 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 User image 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 User image Rich Walsh 2009-10-23 21:13:28 PDT
Created attachment 408179 [details] [diff] [review]
fix for 1.9.2
Comment 3 User image 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 User image 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 User image Peter Weilbacher 2009-11-04 15:08:32 PST
Pushed to both branches (trunk will follow in bug 522896, hopefully soon):

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