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)
Tracking
()
RESOLVED
FIXED
People
(Reporter: mozbugz, Assigned: jimm)
References
Details
Attachments
(2 files, 1 obsolete file)
(deleted),
patch
|
jimm
:
review-
|
Details | Diff | Splinter Review |
(deleted),
patch
|
robarnold
:
review+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•14 years ago
|
||
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.
Assignee | ||
Comment 2•14 years ago
|
||
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
Assignee | ||
Comment 3•14 years ago
|
||
We currently display glass with fullscreen mode, but we're setting the window to opaque via css.
Attachment #454395 -
Flags: review?
Assignee | ||
Updated•14 years ago
|
Attachment #454395 -
Flags: review? → review?(dao)
Assignee | ||
Comment 4•14 years ago
|
||
Attachment #454393 -
Attachment is obsolete: true
Attachment #454396 -
Flags: review?(tellrob)
Comment 5•14 years ago
|
||
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 6•14 years ago
|
||
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+
Assignee | ||
Comment 7•14 years ago
|
||
(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!
Assignee | ||
Comment 8•14 years ago
|
||
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-
Assignee | ||
Updated•14 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 9•14 years ago
|
||
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•