Hacker News new | ask | show | jobs
by Hoffmannnn 4404 days ago
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.

3 comments

Why can't we have the best of both worlds?

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.

> Why can't we have the best of both worlds?

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.

4) Dragging on an actual tab = Drag the tab.

Funny you should mention double-clicking

5) double clicking the tab bar = New tab

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.

> 5) double clicking the tab bar = New tab

Does Opera really do this? Firefox and Chrome don't, and for good reasons, I think.

Firefox does this, on OS X at least.
But 1) and 3) don't make sense together. In 1) you are apparently clicking a tab but in 3) if you drag the same pixel, it's no longer a tab.
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.
Which use case do you think happens more frequently?