Joel Spolsky wrote about something similar with Microsoft missing its Start button placement by two pixels:
> the Windows 95 team missed the point completely with the Start push button, sitting almost in the bottom left corner of the screen, but not exactly. In fact, it's about 2 pixels away from the bottom and 2 pixels from the left of the screen. So, for the sake of a couple of pixels, Microsoft literally "snatches defeat from the jaws of victory", Tog writes, and makes it that much harder to acquire the start button.
This was also the case with minimized applications in Windows 95 and as such you could click below the box.
In Windows 98 they realized the mistake - but in a typical Microsoft way of solving things, instead of simply making the area clickable below they instead forced the mouse up by 2-3 pixels every time you decided to be so silly as to try and click below the box.
I believe there is a technical reason for that 2 pixel move. If I remember correctly, old 16 bits applications can receive mouse messages from minimized windows. They didn't want to break compatibility by posting out of bounds messages.
Don't encourage this way of thinking too much. The gnome folks seem to think "hot corners" are awesome because they are easy to hit with a mouse. The problems is that they are also making something that looks like a touch interface, where the corners are awkward if at all possible to hit. Not to mention they lack visual ques. That said, the w95 start button probably should have extended to the corner.
Was it GOMS back in the early 80s which was the first to teach putting the most important and frequently accessed buttons in the corners so they are easy to click by over-reaching with the mouse?
I never noticed, because I always used the keyboard to get at the start menu. Come to think of it, when I learned all the keyboard commands to manipulate windows, I only ever used the mouse in rare circumstances.
That one pixel is how all windows applications should work. I've been an Opera user for a long time and at some point that one pixel was the only thing stopping me from moving to chrome.
Here's the deal: when you have multiple monitors, the windows mechanic of click+dragging a full screen application's titlebar is the best way to shift applications from screen to screen. With Opera, I just throw my mouse to the top of the screen and drag. With Firefox and Chrome, I have to search out a tiny 20 pixel wide hitbox between the end of the tabs and the minimize button to start the drag action.
Every single windows application I've used respects this mechanic, except for Chrome and Firefox. I actually brought this up with the Firefox UI team on reddit and they agreed that it's broken but evidently decided to keep it because people like OP now expect it.
I'm actually looking for a way to enable this on chrome/FF.
This is why I always use alt+drag to move windows around on my Linux system. I can't really live without.
A few years ago I moved back to Windows for some time and missed that behaviour that much that I ended up writing a small program in C++ that hooks into the windows API and injects that behavior. Never felt better in my life using windows (it also does other stuff like allow alt+right-drag to resize and the option to remove all windows borders).
Here's the program in case anybody is interested but keep in mind it can have a few bugs and I stopped using/working on it because I don't use Windows anymore. Not sure how well (if anything) it works on Windows 8+.
AltDrag is fantastic. It's the first thing I install on any windows computer I'm on. As an added bonus it supports toggling "Always on Top" status of arbitrary windows.
For completeness: AltDrag also supports resize, maximise, and always on top. I believe it has minimize as well, but I don't use that shortcut so I'm not sure.
I love this comment. Not because I agree, I would actually prefer it without it. But because it's the perfect example of how hard is to get everyone happy. Pixel? Fullscreen users are not happy. No pixel? Multi-screen users are not happy. Make it a setting? Than you have to make settings for all and it gets messy/complicated!
Ideally, this should be decided (or configured) by your window manager. But then, I also think that application tabs should be handled by the window manager somehow.
In an overall Windows user experience? Definitely moving windows between screens. Selecting tabs is a pretty niche and uncommon feature across the OS.
It's not about which action is more common, its about the fact that the titlebar drag gesture is universal cross windows 7/8 and is a key element of the user experience.
There are exactly two apps I've used in the entire history of windows 7 that broke this interaction: Chrome and FF. The fault is on those browsers breaking expected behavior, not Opera for doing what windows users expect. The FF UX team admitted that they overlooked this but its understandable that they're keeping it as users have come to expect it.
Multiscreen usage is exceedingly rare, except among hn readers. Among that crowd having lots of tabs open is the norm. So, the subsegment of multiscreen users who don't use a lot of tabs is probably vanishingly small. Myself I'm a windows user a majority of the time and I strongly prefer chrome's behavior.
Another thing lots of applications with custom title bars get wrong: double-clicking the top-left corner of the window (where the icon is, usually) should close the application. (Firefox is an offender here, too, though Chrome is not.)
I had no idea this is a thing, which is.. surprising to say the least. That explains a lot of what I thought were crashes, but wow is that user hostile.
I'm really hesitant to say Firefox gets it "wrong" even if it is inconsistent.
Why not have a way for the window to convey to the window manager that it (the window) is primarily just a holder of tabs (as most browsers, and increasingly more applications, seem to be), and let the WM decide based on the user's preference what the correct behavior and display is?
Is there still not a single window manager that understands tabs as a first class object? Why does Chrome (the browser) give me all sorts of fancy tab-related features, but no other program does? Even Windows nearly got this right back in the 3.1 days of MDI, and the entire world has regressed since then.
Because window manager is hard to extend and hard to customize . I can trivially change this and lots of other things in Firefox, but with windows WM i would have to wait 3 years to get any bug fixed or a new feature added.
Also calling chrome or Firefox window "just a holder of tabs" isn't fair, they are very special holders of very special tabs, and lots of work goes into them to make them work properly. Also there are other "holder of tabs" windows, e.g Sublime Text, which are mostly similar but have important differences. Trying to move all that complexity into WM simply won't work.
In Firefox 29+, you can activate Menu bar which is ~20px high if you want that draggable handle: right-click on an empty space in the top row (not occupied by a tab), or a "+" button, and tick "Menu bar".
I'm also using [Win]+[Shift]+arrows for moving between multiple monitors like others suggested.
In windows 7 (skipped Vista) I'm using [Win]+Arrow to move windows around. With multi-monitor setup it is impossible to attach a window to one side of junction with a mouse anyway.
If you're willing to try something even more odd, I'd recommend a window tiling program like Winsplit Revolution for automatic resizing and positioning of Windows in a much more finely controllable way that is allowed with Windows keyboard shortcuts by default.
I use 3 monitors and it helps me get around window management quirks entirely, while also making dealing with Windows much faster.
You should consider using another Window Manager. With Uniy, you could just drag the (prior) global menu, the panel at the top of the screen, and move the window like that. There are others that would force a normal titlebar there, so you could drag that.
This is definitely on purpose.
The author's use case is, they want to switch tabs, and they want to do so by simply move the mouse to the top of the screen and clicking.
MY use case is, I want to quickly move the maximized window around between monitors, or to drag it away from the top, and thus de-maximize it. The way every other application does it, is by leaving a title bar at the top, which you can click and drag.
If I instead wanted to switch tabs, I would use the usual shortcuts, ctrl tab and ctrl shift tab. In my mind, this is a better option than breaking the "move window by clicking titlebar" behavior.
If the user clicks on the topmost pixel and immediately releases the button, they're probably trying to click on a tab. If the user moves the mouse while holding the button, they're probably trying to drag the whole window.
jQuery UI allows me to make things both clickable and draggable, and it always understands which of the two actions I'm trying to perform. There's no reason why a native app shouldn't be able to implement a similar feature.
If they move the mouse while holding the button, how do you tell the difference between trying to move the window, and trying to move just that one tab?
When you're trying to reorder tabs, you are much more likely to click on the tab itself, not the pixel above it. Try it yourself, it happens naturally. Drag-and-drop usually involves more precise mouse control than simple clicking.
So the software can safely assume that if you drag the top pixel, you're trying to move the window rather than the tab.
Because then the UI will be confusing - the same place and action (clicking in the top) will affect either application or window manager. Also, sometimes you want to drag tabs around to e.g. reorder them or move to a new window.
Clicking != dragging. Same place, different action. Just because dragging starts by clicking doesn't mean that the computer should react in the same way. Double-clicking also starts by clicking, but most computers are perfectly capable of reacting differently to a double-click.
Switching to a tab upon clicking the top pixel is also perfectly consistent with what usually happens when you click on the chrome of any window:
1) Clicking on the title bar (top pixel) = Switch to window, and activate the element at pointer location, which in this case is a tab. Try clicking on the "Minimize" button of any background window to see this paradigm in action. The window is brought to the foreground and immediately minimized.
2) Clicking on an actual tab = Switch to tab.
3) Dragging on the title bar (top pixel) = Drag the window.
6) double clicking the title bar = Maximize/Restore
And then you double-click the titlebar instead of the tabbar by mistake and your window jumps away.
Or just have a stupid option and let the user decide. Maybe have that context-sensitive behaviour as default, but let me say that I want the title bar to be the title bar and tab bar to be the tab bar and have the two not mix together.
If you click, it's a tab. If you drag, it's a window. What's so difficult about that? There's no reason to click on a window that is already fullscreen, anyway. (OP's problem only occurs if the browser is fullscreen.)
No, it's not. De-maximizing a window can be done in O(1) operations by other methods (click the widget at the top right of the window, or alt-space to get the keyboard menu) whereas if you have a bunch of tabs open, navigating to an arbitrary one with ctrl-tab takes O(N) operations, so clicking on a tab should take precedence.
Also note that it's available through the regular settings UI (opera://settings/) if you enable advanced settings under User Interface you will find "Disable tab bar's top spacing when browser window is maximized".
Actually, in this case, the target of the top of the screen is actually infinite in one direction. The mouse pointer will stop moving there, and it's as if the tab is infinitely tall.
Is that really a bug as others are saying? I've always thought of it as making the inverse of the Windows 7 drag-to-top-of-screen-to-maximize (restoring the window) easier, and prefer it that way. More generally, it makes it easier to drag the whole window around again after maximization.
In some sense, it makes Opera at least somewhat more consistent with other regular Windows applications that don't mess around with the titlebar. I actually find it annoying that there's no quick way to manage the maximized browser windows in Chrome or Firefox other than to click that button in the standard window chrome to restore the window, and then proceed.
Well... sure, I guess, but although I wasn't direct about it in my above comment, the whole discussion was about mouse control right?
If we want to discuss keyboard shortcuts, then Ctrl+Tab/Ctrl+Shift+Tab/Ctrl+W/Ctrl+T are quick tab management shortcuts that bypass mouse control as well, and that one pixel at the top that makes tab switching by mouse annoying for talles would be rather moot.
I notice this happens only when the window is maximized, since otherwise you have gap above the tabs.
I don't think it's a bug. I think is is done so that you can move the window by dragging that one pixel bar.
In both Firefox and Chrome if you want to move the window when you have the window maximized, dragging on the top of the tab detaches the tab from the current window. The only way to move the window is to move the cursor to a space where you don't have a tab or by clicking on the restore button (the middle button on top right).
When you have lots of tabs open then there is no blank space on the right of the tabs to hold the window and move it.
Usually, I've noticed Opera users to have lots and lots of tabs open, which doesn't leave any blank space on the right of the bar. At that time this one pixel is a life saver to move the window without needing to go all the way to the top right to restore the window.
"The only way to move the window is to move the cursor to a space where you don't have a tab"
This may be true in whatever window manager you're using, but it's not true for all of them, including the one I use (dwm). Better window managers let you move and resize windows without having to click on special places that may or may not be provided by the programs that draw the windows.
OSX is full of this sort of rubbish - I can't count the number of times I've moused over to the right side of the screen to scroll a window, only to start moving the whole goddam thing instead. Also related, OSX menu items have a gap between them; clicking on that gap closes the menu (I think). I cannot think of any good reason for that, only bad ones. It's infuriating when an OS gets so many usability things right, then falls down on the hugely obvious bits.
> Also related, OSX menu items have a gap between them; clicking on that gap closes the menu (I think).
There isn't a gap between every menu item, but clicking on the horizontal dividers or disabled menu items does close the menu without doing anything. The way that Windows does it seems better, there it does nothing at all, not even closing the menu.
Good point - it's only on menu dividers that this occurs. It just so happens that some menus (e.g. the main "Chrome" one) have a divider for every other item, and the dividers are about 10 pixels tall. I much prefer the Windows approach, but I'm not sure even that makes as much sense as just selecting whichever item is closest.
That's such an obvious and disastrous user interface bug that I presume it's the result of some specific process rather late in the software build process (perhaps only on some platforms). Otherwise, I can't imagine any of Opera's user interface testers not noticing this.
Similarly, Windows 95’s Start Menu ripped off the Mac's apple menu, but with a fatal flaw: if you slammed the cursor all the way into the corner, unlike on the Mac, you would be unable to click the button.
Chrome's tabs are full height when Chrome is in full screen, but not when vertically maximized in Windows 7.
Anyone who snaps windows to the side of the screen might run into a similar problem, though the visual gap is much more apparent since it's much larger than a pixel, so it's far less confusing.
When I first switched from Windows to OS X, I frequently had what I call the "Maximized Window Off by One Pixel" problem.
Since there is no "maximize" button on OS X, I would always manually maximize my browser window. But since humans are imperfect, occasionally I would resize the window 1px from the right edge. When I wanted to scroll down (without using the mouse wheel), I would flick the mouse cursor to the right edge of the screen and "click" to start the scrollbar drag, which of course would click a background window and infuriate the heck out of me. I have since adapted to never use the scrollbar.
Chrome was the first browser to handle that one pixel specially, and Firefox followed quickly (around version 4 or so). For some reason Opera never copies it.
It used to be a big deal when I spend most of my time with a single monitor. With dual monitors, Xmonad keeps a one-pixel border around the active window so "move the mouse all the way up and click" doesn't work anymore. You choose your own poison :)
Only when reading this thread that I realized there are people preferring Opera's behavior, which is kinda eye-opening.
Sometimes I like leaning back in my chair and browsing one handed. Sometimes, it's the mouse hand, other times it's the keyboard handing (using shortcuts). Usually mouse hand though.
It's not that simple, if i want to move a tab i don't want to move any random tab, so i still have to aim horizontally, and effect of Fitts's Law is much smaller. I for one never tried to drag a tab from top one pixel. On the other hand for dragging a window horizontal precision doesn't matter much, and that one top pixel is really useful.
> the Windows 95 team missed the point completely with the Start push button, sitting almost in the bottom left corner of the screen, but not exactly. In fact, it's about 2 pixels away from the bottom and 2 pixels from the left of the screen. So, for the sake of a couple of pixels, Microsoft literally "snatches defeat from the jaws of victory", Tog writes, and makes it that much harder to acquire the start button.
http://www.joelonsoftware.com/uibook/chapters/fog0000000063....
(edited link to point to second article in Spolsky's series)