Why have reverse tabs won? Has anyone done any usability test on them?
On OS X, with a space left for the hit area of only 10px tall, it's really hard to drag a window that uses them. For context, 10px is about half the cursor's height.
I can see a reason for them on Win/Linux, but I find them completely unfit for the Mac. I guess people just maximize the window and leave it at that.
On the other hand, I'm glad there's still a distinction between the search box and the address bar. The annoyance of omnibar mistaking a url for a search query and vice-versa, even admitting it's a rare event, is not worth the trouble to me. Besides, educating the user on such difference seems important to me.
I thought about it a bit and decided I prefer reverse tabs (tabs above the address bar, not below) because I see the address bar as part of the page I'm visiting - as I change tabs, the address and page display changes to, so having both of these together on the screen makes sense to me.
To me, as I read the brower window top-down, I have the firefox menu and minimise/maximise/close buttons -> the tabs -> the address bar and back/forward buttons. That follows the logic of application -> 'threads' within application -> status of that thread and forms the more logical tree from general to detailed in my mind.
That's not to say it's better or worse than the alternative, it's just different and makes more sense to me.
1) I'm not running OSX so it's double the size for me.
2) there's a whopping great area to the right of the 3-4 tabs I generally have open at any one time. This is the aformentioned ~20px plus the height of the tab itself. Secondly, there's the area beneath the mininmise/maximise/close buttons and the new hamburger menu button, which can be dragged in a pinch to move the window if tabs go all the way across. Tabs don't overflow to this point and it's 26px in height. Note for reference the "1" in the white box for HTTPS Everywhere is pretty much the height of the cursor. [1]
3) Even if I had a comically sized mouse cursor, I can enable the menu bar at the top to pad a bit of extra space (presuming I can live with the idea of having 'File', etc. across part of it) which bumps it up to ~25px.
The size of the window-drag click target is orthogonal to whether tabs are above or below the address bar. What you really want is a title bar, not necessarily tabs below the toolbar.
And you can get that. In Firefox 29, open Menu > Customize and toggle the Title Bar button at the bottom left. That will give you a normal-height title bar to drag the window with, while still keeping tabs on top to reflect that switching tabs also changes the state of the URL in the toolbar.
Because Chrome. There's no other reason. It's obviously less efficient due to Fitt's law and the comparative distances the mouse pointer must travel, but you'd hear the designers justify it how "conceptually" the address bar should be inside a tab. Not if it hampers productivity it shouldn't.
I don't care where the tabs go by default, as long as we have an option to move them if we want. Unfortunately, as Mozilla are turning into google, they have decided choice is evil and bad.
I can see a reason for them on Win/Linux, but I find them completely unfit for the Mac. I guess people just maximize the window and leave it at that.
On the other hand, I'm glad there's still a distinction between the search box and the address bar. The annoyance of omnibar mistaking a url for a search query and vice-versa, even admitting it's a rare event, is not worth the trouble to me. Besides, educating the user on such difference seems important to me.