Closed Bug 575044 Opened 14 years ago Closed 14 years ago

Enabling and Disabling Fullscreen mode produces irregular results with window and controls placement

Categories

(Firefox :: General, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: mozbugz, Assigned: jimm)

References

Details

Attachments

(2 files, 1 obsolete file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a6pre) Gecko/20100626 Minefield/3.7a6pre Firefox/3.6.6 Build Identifier: There are possible several distinct bugs for Full screen issues with the intent that if so, this bug could more of a meta bug to spin them off, or if a general solution would solve these cases then so be it. Here is a list of FS issues I've come across: 1) The window titlebar never leaves the scene going from normal window mode to full screen produced a window the size of my monitor screen in fullscreen mode but wasn't maximized. 2) If I went to maximized first, then to Full screen mode, it was out to the edges. 3) if I had the menu bar in place hitting F11 produced different results when having the app menu button. 4) hitting F11 multiple times between each state produced controls that rolled under or rolled over the titlebar. 5) Some times the full screen toolbars were cut in half other times the app menu stayed and the controls went underneath. Other times the controls disappeared completely and couldn't use the mouse to bring them down. 6) If I held down the F11 key it would switch back and forth between over and under the titlebar that was still showing.. 7) I was also about to get into a state where the menu bar was *IN* the titlebar, and the titlebar didn't exist. Though don't know how that occurred except maybe holding down F11 or hitting F11 a zillion times. Reproducible: Always Steps to Reproduce: D2D off. Play with going from normal window/maximized modes to full screen states and in out of various paths. Actual Results: Use of Fullscreen mode varies depending on menu bar or app menu or normal window or maximized window use and repeated use of F11 in and out of Fullscreen and the mouse. Expected Results: Some consistent behavior as before drawing in titlebar/app menu landed. Just wanted to file this to get my thoughts down since there were so many STR with the intention that it could be spun to several specific STR bugs or to see if it was a more general problem.
Blocks: 513162
I can even get into CSS background mode from bug 567742 if I hold down the F11 key for a while and then release F11, I can see it show up, in which case the titlebar disappears like its suppose to. If I hit F11 two more times, it goes back to messed up mode.
Attached patch widget changes (obsolete) (deleted) — Splinter Review
Adds support for a size mode = nsSizeMode_Fullscreen, and honors it. Non client margins get disabled when we kick into this mode.
Assignee: nobody → jmathies
Attached patch browser css (deleted) — Splinter Review
We currently display glass with fullscreen mode, but we're setting the window to opaque via css.
Attachment #454395 - Flags: review?
Attachment #454395 - Flags: review? → review?(dao)
Attached patch widget changes (deleted) — Splinter Review
Attachment #454393 - Attachment is obsolete: true
Attachment #454396 - Flags: review?(tellrob)
If the goal is to revert the disabling of glass for fullscreen mode, you should just remove these rules (they duplicate the rules just above). Are those rules actually part of the problem, or are you just reverting them because the core patch fixes the issues described in bug 567742?
Comment on attachment 454396 [details] [diff] [review] widget changes >- return nsBaseWidget::MakeFullScreen(aFullScreen); >+ if (aFullScreen) { >+ mOldSizeMode = mSizeMode; >+ mSizeMode = nsSizeMode_Fullscreen; >+ } else { >+ mSizeMode = mOldSizeMode; >+ } >+ >+ UpdateNonClientMargins(); >+ >+ // Will call hide chrome, reposition window >+ nsBaseWidget::MakeFullScreen(aFullScreen); >+ >+ return NS_OK; > #endif Why are we ignoring the return value of nsBaseWidget::MakeFullScreen where before we return it? >- if (mSizeMode == nsSizeMode_Fullscreen) >- MakeFullScreen(TRUE); >+ //if (mSizeMode == nsSizeMode_Fullscreen) >+ // MakeFullScreen(TRUE); Leave it in or take it out. Otherwise the changes look good though I'm biased because I wrote most of them!
Attachment #454396 - Flags: review?(tellrob) → review+
(In reply to comment #6) > (From update of attachment 454396 [details] [diff] [review]) > >- return nsBaseWidget::MakeFullScreen(aFullScreen); > >+ if (aFullScreen) { > >+ mOldSizeMode = mSizeMode; > >+ mSizeMode = nsSizeMode_Fullscreen; > >+ } else { > >+ mSizeMode = mOldSizeMode; > >+ } > >+ > >+ UpdateNonClientMargins(); > >+ > >+ // Will call hide chrome, reposition window > >+ nsBaseWidget::MakeFullScreen(aFullScreen); > >+ > >+ return NS_OK; > > #endif > > Why are we ignoring the return value of nsBaseWidget::MakeFullScreen where > before we return it? It always returns NS_OK, but that could change I suppose. Will update. > > >- if (mSizeMode == nsSizeMode_Fullscreen) > >- MakeFullScreen(TRUE); > >+ //if (mSizeMode == nsSizeMode_Fullscreen) > >+ // MakeFullScreen(TRUE); > > Leave it in or take it out. > > Otherwise the changes look good though I'm biased because I wrote most of them! Will remove!
Comment on attachment 454395 [details] [diff] [review] browser css I'll file a new bug on the fx button being visible in fullscreen mode.
Attachment #454395 - Flags: review?(dao) → review-
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 575155
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Depends on: 575222
No longer blocks: 575155
Depends on: 584358
Depends on: 587517
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: