Closed Bug 251599 Opened 20 years ago Closed 15 years ago

Unnecessary resize grippy appears after exiting full screen mode

Categories

(Core :: Widget, defect)

defect
Not set
trivial

Tracking

()

RESOLVED FIXED
mozilla1.9.2a1

People

(Reporter: skydaemon80, Unassigned)

References

Details

(Keywords: polish, useless-UI, Whiteboard: [polish-hard] [polish-interactive][polish-p2])

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040714 Firefox/0.9.1+
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040714 Firefox/0.9.1+

Unlike the browser window of the Mozilla suite, the window resize grippy is not
visible if the Firefox window is maximized, which is the desired behaviour. 
However, after exiting full screen viewing mode, the window resize grippy
appears on the bottom right corner of the already-maximized Firefox window.  

Reproducible: Always
Steps to Reproduce:
1. Ensure the status bar is visible (use View | Status Bar to enable it).
2. Maximize the Firefox window if it is not already maximized.
3. Toggle full screen mode on, then off (View | Full Screen, or press F11).
Actual Results:  
The window resize grippy appears on the far right of the status bar.  The
unnecessary resize grippy disappears only if the window is restored, then
maximized again, or if the window is minimized, then maximized.

Expected Results:  
No resize grippy should appear on the far right of the status bar.  The status
bar should have the exact same appearance as before entering full screen mode.
Added keyword useless-UI because if the window is already at max when you go into full screen mode and then return from full screen mode the grippy serves no purpose since the window is already at max. Only serves a purpose if the window wasn't at max when you go into full screen mode.
Severity: minor → trivial
Keywords: useless-UI
OS: Windows 98 → All
Assignee: firefox → nobody
Hardware: PC → All
*** Bug 337072 has been marked as a duplicate of this bug. ***
*** Bug 340364 has been marked as a duplicate of this bug. ***
This may help: something about the AutoHide plugin (available at http://www.krickelkrackel.de/autohide/ ) hides that unnecessary grippy somehow.  Conversely, something about the FullerScreen plugin (available at https://addons.mozilla.org/en-US/firefox/addon/4650 ) does *not*.  I haven't investigated further than this yet.  Installing both together hides the grippy.
Not only does this grippy appear, but it allows a window resize, which should not be an available option when a window is maximized.
I can confirm this behavior.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007090405 Firefox ID:2007090405
There's been no activity on this bug for a year; are there any keywords to add or people to cc to make progress on this?
Keywords: polish
Whiteboard: [polish-hard] [polish-interactive]
Actually, it looks like they have tried to fix this by always providing the grippy and restoring the window when it is clicked. Unfortunately, the bug still exists, and the window is not restored when the grippy is clicked after exiting fullscreen mode.

I wonder if it's worth contacting the creator of AutoHide, as he/she seems to have written code that can solve this...
Component: General → Widget
Product: Firefox → Core
QA Contact: general → general
Blocks: 176640
P3 - Polish issue that is in a secondary interface, occasionally encountered, or is not easily identifiable.

Technically this is in the main window (primary interface), but the placement in the far corner of the screen means that most users are not incredibly likely to notice the problem.
Priority: -- → P3
(switching to whiteboard for polish-relative priorities)
Priority: P3 → --
Whiteboard: [polish-hard] [polish-interactive] → [polish-hard] [polish-interactive][polish-p3]
FWIW -- You're right, it's not easily noticeable...until you have addons that add items to the status bar in that corner.  E.g., I have AdBlock Plus down there, as well as Perspectives, and on this page I have the padlock icon too.  So that's three colorful icons in the corner, and when flipping to fullscreen and back, those icons jiggle out of place.  When the grippy disappears (which it does either after an alt-tab or a mouseover the window border, I forget which but can't test right now since I have Autohide installed), those icons jiggle back into place, and that movement draws the eye down there in a Huh? reaction.  :)
>those icons
>jiggle back into place, and that movement draws the eye down there in a Huh?
>reaction.  :)

Yep, movement is much easier to notice than something appearing or disappearing.  However since the noticeable movement requires extensions to be installed, this still feels "occasionally encountered" (in terms of the user base as a whole), although for a subset of users it may be constantly encountered.
I agree -- but don't forget the padlock.  That's not an addon; that's just secure browsing.  It's become less of an issue for me at the moment, as I've just turned off the status bar altogether, but it could indeed be a constant issue for a subset of users.
Good point, I honestly can never remember what our current decision is on keeping or removing the padlock.  It looks like we kept it again, so raising to P2.
Whiteboard: [polish-hard] [polish-interactive][polish-p3] → [polish-hard] [polish-interactive][polish-p2]
Seems like bug 484488 fixed this.
Status: NEW → RESOLVED
Closed: 15 years ago
Depends on: 484488
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
I missed Dao's comment from several months ago, and am double checking again...  Looks like both he and Joseph are right -- with Fx3.5.5 in safe mode (to avoid any confusion from AutoHide or other extensions), the resolution is to always display the grippy, in normal and maximized window modes, and after going to fullscreen and returning, it's still there.

That's consistent...but not expected Windows behavior.  I don't have an Fx3.6 install to test at the moment; might this have changed for future versions?
You need to log in before you can comment on or make changes to this bug.