Closed Bug 121150 Opened 18 years ago Closed 7 years ago
Status Bar resize grip should disappear when window is maximized
Mozilla build build 2002012103, Windows XP pro. - Start Mozilla - Make the Status Bar visible, size grip appears right-bottom of the window - Maximize window Expected result: size grip disappears Actual result: size grip still visible.
The grip still functions though.. its kinda nice actually.. INVALID?
Indeed the size grip functions, but I think it is confusing. Some arguments: - For Windows, it is normal behavior to remove the size grip when maximized. - When maximized, a window is not resizable, menu option ‘Size’ is disabled, and borders cannot be used to resize. - Clicking on the size grip when the window is maximized introduces new functionality ‘remove maximized state and resize window to the maximized size’ - It confused me, I thought the window was not maximized when I looked to the right-bottom corner of the window, which indicated ‘resizable’ which normally means ‘not maximized’.
I think the reporter makes a good point. All other apps in Windows, including IE, lose the grippy - including its functionality - when maximized. In the interests of confusing users as little as possible, I'd say this bug is at least valid and even worth fixing, even if it does in fact remove functionality (that's technically not supposed to be there). Altered summary just a bit (changed "still visible" to "should disappear"). Changing from Browser-General to UI design.
Component: Browser-General → User Interface Design
Summary: Status Bar resize grip still visible when window is maximized → Status Bar resize grip should disappear when window is maximized
->XPApps GUI Features. I do not have XP to test. Is this still a problem on current builds (0.9.8 or newer) and does it appear in both classic and modern themes or just Classic?
Assignee: asa → blaker
Component: User Interface Design → XP Apps: GUI Features
QA Contact: doronr → sairuh
It's behavoir in both Classic and Modern, and appears in the latest builds (tested on 2002021108, Windows XP Pro)
i support the fixing of this bug, resizing a maximized window is kinda strange on Windows(R) operating system, and it is quite funny to resize the window :)
*** Bug 124088 has been marked as a duplicate of this bug. ***
Confirming. This still happens in RC1, WinXP, modern theme (possibly classic as well). This should definately be fixed, preferably for 1.0. This bug makes Moz stand out from all other Windows apps, even though it's not serious, it is confusing to a user, and this kind of beats the point of having a maximized window... Fixing this shouldn't be hard anyway.
I can still see the problem in Win32 nightly build 2002120604.
*** Bug 185413 has been marked as a duplicate of this bug. ***
Assignee: bross2 → guifeatures
QA Contact: bugzilla
Filter "spam" on "guifeatures-nobody-20080610".
Assignee: guifeatures → nobody
QA Contact: guifeatures
This is indeed a bug, not a feature, if Firefox loses focus, then regains it, the resizing grippy goes away. This little bit of info could allow a simple program to fix this... a rather annoying work-around... But I'll see what I can do
Seems like this worked fine for a while, then was regressed again (in Firefox): bug 419292. Not closing this bug though, since it's in SeaMonkey component, and it's not clear if the fix is application-specific.
Depends on: 419292
In SeaMonkey 2.0 this grip seems to have disappeared. Is it possible to have it restored? I liked it because you could easily drag the window smaller if it was maximized. Current behavior for me on Windows is if started maximized it doesn't show, if resized (using top middle resize button), and back to maximized again, the grip shows bottom right corner and works as ever before in SeaMonkey. I would prefer it if the grip-function was there permanently.
WOKSFORME User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 SeaMonkey/2.22a1 Build identifier: 20130725164147
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.