Closed Bug 643659 Opened 14 years ago Closed 3 months ago

Option for 1px border for aero snap or alternative implementation

Categories

(Firefox :: Theme, enhancement)

Product:
Firefox
Component:
Theme
Platform:
All
Windows 7
Type:
enhancement

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: peterthorpe81, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0 Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0 In previous betas of tabs on top in Windows 7 there was a 1px space at the top so you could move your mouse right to the top of the browser and use the aero features: Double click to Restore down/Maximize Drag left or right to snap left or right of monitor or just move it in a non-maximized state This is really handy functionality and a lot of Windows 7 users use it barely using the original control box in the top right. In the new release this space has been removed (after it was added in an earlier beta). The space around the Orange Firefox button and in the top right is not appropriate for the functionality as it defeats the purpose and doesn't match a normal windows programs functionality. I can understand that you want the tabs to be just as easy to access by them Fitt's law and all but Fitt's law is already in use for the great Windows functionality. Please either: 1. add an option to enable/disable the 1px border for aero snap 2. implement double tap on a tab to perform Restore down/Maximize and when dragging on a tab use aero snap. I am unsure how you would differentiate a desired browser tab tear from a desired drag for snapping or Restore down/Maximize though. Reproducible: Always Actual Results: No Aero Snap Expected Results: Aero Snap
It was done on purpose in bug 624129. There a little area on the right, between the tabs and the min/max buttons, that you can use for AeroSnap.
Yeah I know it's rubbish though and doesn't match with the expected behaviour of any other windows program. The whole idea of having these features right along the top is you shoot your mouse straight up to the top of the screen and start using it you don't have to make the effort to direct your mouse to an exact area on the screen.
More requests for this are here: https://firefox.uservoice.com/forums/57440-firefox-4-beta/suggestions/1386785-add-1-2-pixel-border-above-tabs-when-maximized-to- @Jo Hermans: as I'm sure you realise, there is a world of a difference between grabbing a maximized titlebar (impossible to miss even if you try) vs grabbing a 10-pixel wide area that has no visible borders (compounded by the buttons on the left which also have no visible borders). The absence of a properly draggable area seriously impairs a standard feature of Win7 that a bunch of people clearly find useful.
Try Google Chome next time - it has the same problem. You also have to hit the empty area on the right (or the little triangle between 2 tabs) to be able to touch the titlebar and display the system context menu or whatever. The areas are a little bigger though. Note that this is specific for Windows 7 - normally a titlebar would not be used a lot when the window is maximized. Fitt's Law then becomes important, and people were accidentally hitting the titlebar, when they wanted to hit the tab.
Yes, Chrome messes this up too, and that's a major reason I stay off Chrome. It is really rather annoying for anyone used to large screens or dual screens - i.e. those people who don't just leave their browser permanently maximized. This isn't specific to Windows 7 only. My guess is it also applies to all future versions of the OS for at least a decade. The "normally" will change as more and more people move off WinXP. But even in Win XP, the titlebar was very useful for double-clicking to restore a maximized window - since it's that much easier to hit than the tiny "restore" button. You bring up Fitt's Law but apply it to tabs only, not the titlebar. But obviously it applies to every control that's actually used. The titlebar is just such a control for some people. I happen to use it a lot. If one is going to violate the principles of an OS, it would be nice to at least offer an option to stop that, like this bug requests.
There seems to be a bit of misappreciation about the consequences of features like this which break an OS-wide behaviour for a single application. It is very hard (perhaps impossible) for someone who doesn’t use such an OS-wide feature to appreciate the difference it makes to someone who does. For this specific case of dragging titlebars, I assume it goes something like this: * The user needs to do something in some application (doesn’t matter which). * There is a window in the way. * The user instinctively (out of habit) pulls the mouse up and drags the titlebar. The user doesn’t think about this; he expects this to work because it works almost all of the time. * The user’s brain is now already beginning to plan the next moment: visually scanning the area of the screen that was previously covered by the window. * At this point the user may notice that the window hasn’t moved. This brutally pulls the user’s thoughts out of his flow; he now has to interrupt the mental process that he was in and become conscious enough to: * Realise that the malfunctioning window is Firefox (yes, “malfunctioning” is the right word because it didn’t do what he expected) * Remember how to work around the malfunction for this obstinate special case * Execute the workaround * Go back to the previous thought This kind of interruption is frustrating — and not just once, but every single time it happens. It’s like an obstinate child that doesn’t do as its told when all the other 30 children in the class do. It’s like a drunkard yelling in a library when everyone else knows to be quiet. It’s screaming “I am special and you have to do something different for me than for everyone else.” There are many other OS features that a software can potentially break that cause exactly the same kind of confusion. For example, imagine a program subtly changes your keyboard layout so that every time you type “it’s” you get “itś”, but only in this one program. Or imagine a program that moves the window close button (the X) to the other end of the titlebar, and/or overrides Alt+F4. All of these examples have exactly the same mental consequences that I described above. I hope that I am able to convey the real-life consequences of this feature to allow the Mozilla foundation to make a reasoned decision on it. I hope the decision will be to stop breaking widely-used OS functionality.
@timwi good message that is the frustration I go through 10-20 times a day except sometimes worse because if you drag a tab rather than the window far enough of course it tears off into a new firefox window and then you have to put it back. The previous functionality in betas with the gap was the desired functionality for me I don't want a chrome clone implementation but still want to save the space of tabs on top.
Don't forget that you're violating Fitt's Law if you add the border again - people complained about that too !
Consider this, in the current implementation users who wish to use the windows functionality (including xp double tap) need to select a gap of roughly 16px between each tab where the tab doesn't highlight or similar sized gaps to the left and right. That requires a much high degree of accuracy as oppose to hitting a say 200px x 20px tab. Also bearing in mind the tab is minimally below the top of the screen so shooting your pointer to the top is still useful with a tiny adjustment downwards to select the tab, the reverse isn't true without the gap the functionality must be found with much finer mouse control. This indicates to me the best default implementation for windows is with a gap as Fitt's law is used to its best advantage. Besides which this is a request for options.
Why not just make the browser.tabs.drawInTitlebar a visible pref right under the "Tabs On Top" context menu item? People who want Fitt's law can turn it on, and people who don't want Fitt's law will get their draggable titlebar.
I think you are missing that both uses are examples of Fitt’s Law. One of them is specific to Firefox tabs, while the other is global to all of Windows 7. To have the tabs at the top violates Windows 7’s global use of Fitt’s Law, while adding the suggested border violates only Firefox’s.
Let me approach this from a different direction. When not maximized, there is quite a sizable title bar available. Why is this? Presumably it's because you expect that the users might actually want to use it, to drag the window around. Presumably the idea was that this doesn't apply in maximized mode. Clearly that idea is wrong; the titlebar is as useful for dragging the window when maximized as it is when it's restored, in Win7 at least. Hence this request.
@Benjamin browser.tabs.drawInTitlebar leaves a full gap of normal titlebar width. This isn't what I was asking for, I was asking for the previous functionality which was the tiny 1-2px spacing at the top. This saved most of the space while letting you access the windows features. @Roman yes when maximized I would only need the small gap though not the full titlebar as you are just shooting you mouse to the top of the screen. This could also be set when snapped to left or right of the monitor.
I simply can't believe that of all the Devs involved in the creation of Firefox 4, none of them picked up on this issue. I find it hard to believe that not one had a large or dual screen setup with windows 7. What we need is not an about:config workaround, there should be a 1 pixel border by default, for those users that don't make use of aero snap, the difference will be non existant; choosing a new tab requires a coordinated mouse action, grabbing the bar for aero snap does not. Please wake up Moz Devs, seriously poor form :(
@Derek the thing is when tabs on top was added around beta 4 or 5 sort of time it didn't have the gap. Then it was added by request and was in the next few betas then removed again.
Switching focus to a Firefox window is another major issue I found with the current titlebar, having used Firefox 4 a bit. I have a multi-monitor set up and lots of windows open. While Alt+Tab is handy in lots of situations, sometimes it just doesn't cut it: e.g. I spend a while working on monitor A, and then want to browse the web on monitor B. The browser can be anywhere in the alt+tab history now, so the fastest way to focus it is to just click it. Previously the easiest and guaranteed-to-be-safe place to click on was the titlebar. Shove the mouse upwards, towards the centre of the screen, then click. Browser activated. There is no longer a large area where I can consistently aim to click Firefox without indavertently activating something like a button or a link. None at all. I now need to look, to aim. I could either try to avoid some clickable content within a tab, or I could aim for that 16px wide area. Both of these just totally kick me out of my workflow, like Timwi explained so well.
(In reply to comment #13) > @Benjamin browser.tabs.drawInTitlebar leaves a full gap of normal titlebar > width. This isn't what I was asking for, I was asking for the previous > functionality which was the tiny 1-2px spacing at the top. This saved most of > the space while letting you access the windows features. The problem is that a small border gives users the impression that they CAN use Fitt's law to hit the tabs. There is not enough visual distinction. Users end up slamming their mouse against the top of the screen and selecting the titlebar when they really meant to select tabs. I've known of some users complaining that the 2 px border on Windows XP before the tab theme change caused major issues for them. A big border clearly marks that you can not use Fitt's law to hit tabs.
I think arguing that it should be one way or another is futile because both options are "the best option", only for different people. There is already a "Tabs on top" checkbox. I'd love to see a "Collapse title when maximized" option right next to it. By default it's on, and causes the current behaviour. When disabled, it causes a, say, half height titlebar to remain in maximized mode. Thus, those who need the titlebar get the benefit of reduced vertical waste but can also continue to use the title bar as before.
I'd go for half height, 1-2px is way too small.
It's clear to me that Fitt's law is not my law... When a program reacts different than any other program in a certain environment (win7 aero), a person experiences that program as 'sloppy'. That's my law. FF never was sloppy, so I don't see a reason to give that impression now because of some Fitt. If there is a possible conflict with the tabs, look for the best solution: -more than 1 px space -highlighting/shadowing the top space when hovering over it -add it as an option in the preferences But I don't think there will be a lot of problems in practice anyway. Maybe following Fitt's law, but because the tabs are small items for which you have to aim anyway + they highlight when hovering over it, I think the chance you miss a tab only occurs once or twice because one didn't know yet you can drag a maximised window that way. Aero uses the left, right & top side already, so FF (or any other app) should leave it for that (at least optional: [x] Aero compatible titlebar tabs)
God, just add an option.... Is it that hard?
I'd love that option. 1px would be enough for me... ...maybe even a setting in about:config - so nothing a 'normal' user would tamper with.
(In reply to Notlost from comment #21) > God, just add an option.... > Is it that hard? ^it really is this simple. A year on and still nothing, wake up you stupid dips***s and give us the option.
Some time ago thunderbird got also fullscreen tabs like firefox but there the border is there. Could this also be implemented for firefox?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: x86 → All
Version: unspecified → Trunk
What should have been changed for the nightly builds?
I found a plugin that fixes this issue. Maybe it will help someone who has the same problem. https://addons.mozilla.org/en-US/firefox/addon/extra-padding-when-maximize/
(In reply to Pimmetje from comment #26) > I found a plugin that fixes this issue. Maybe it will help someone who has > the same problem. > https://addons.mozilla.org/en-US/firefox/addon/extra-padding-when-maximize/ Thank you sir! I, and i'm sure many others were unaware of this addon. Thanks for posting it here.
Severity: normal → S3

We've had many theme changes since this bug was filed. If it's still applicable in any way it needs to be resubmitted wrt how it applies to the current theme

Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.