If moving items around in the bar required the use of a modifier key, it would be much less likely to have accidental poofs. Same with the Dock. I cannot count the number of times I have had to help users recover their lost Dock icons. It’s ridiculous.

Most of them don’t know how to properly manage the Bookmarks Bar anyway, though. So it’s very likely that the nuances of the two modes is completely lost on them. And most of them don’t use tabs in Safari anyway.

As for people who actually use these features, I think they know enough about what they are doing that they don’t need the extra “protection” that Apple purports to give them through these two modes.

With the bookmarks bar this mode specific dragging makes sense. It’s convenient for the user to grab an item and move it left or right without worrying about precisely dropping it back on the bar. It’s likely that the cursor will stray from the bar while rearranging an item, but through initiating the drag the user is protected against accidental deletion. It look like Safari actually gives preference to horizontal dragging over vertical dragging, if you drag at 60? from the horizonal (i.e. mostly vertical) Safari will still assume you’re wanting to initiate a horizontal drag. You need to show more intent if you want to remove items from the bookmarks bar.

I think they were probably trying to maintain some design integrity when making the tab-bar and bookmarks bar behave in similar ways due to their close proximity. While it isn’t as important to protect the user against spawning new windows compared with deleting a bookmark, it still speeds up the interface (preventing the creation of the translucent page thumbnail when just shuffling tabs) and makes it easy for the user to rearrange tabs without having to keep the cursor along the thin tab-bar strip.

It feels natural to “pluck” the tab off the tab bar to wave it around freely. But I can slide it around in the tab bar while hardly taking my eyes off the page, and I don’t worry about an unexpected change of context by absently dropping it into another window.

I can’t help thinking that the behaviour is more complex, like the split-second pause required to drag a window’s proxy icon or some selected text, but whenever I slow down to test the theory, it just seems like a 45° dragging threshold that determines the result.

Second, if you drag a tab outside the window boundary and the mouse is over the tab bar of another existing Safari window, it should move the tab to that new window regardless of any other rules — even if it’s directly lined up horizontally with the existing window’s tab bar.

(The other tweak I’d make is only tangentially related, but I think you should be able to option-drag a tab to duplicate it.)

Still, I can’t help but feel that the restrictions placed by Apple are quite unnecessary, even on smaller screens. As you pointed out yourself with the single tab behaviour, the whole thing could use a little more fine-tuning.

This is most likely a concession to the ability to drag tabs from one window to another. If you don’t want new pages to open with tabs make sure the menu command says “Show Tab Bar”.

As far as the tab behavior I disagree that the up or down movement is counterintuitive. Considering this is a new behavior and any real life metaphor is limited, how can its behavior be counterintuitive? I feel they are akin to lifting the page out of a ring binder, up then over to a different binder. The up or down move says, “I want to remove this tab from this tab bar.” I think your argument is based on your screen real estate. On most laptops, the windows will not be side by side. On my iBook I will move one window lower than the one behind it and drag the tab up to move it to the other window. So, perhaps it’s a case of not being able to account for all configurations.

The single tab behavior is strange to me. If I have 2 windows each with a single tab, when I select a tab it should automatically create the proxy. Why would I want to move a single tab horizontally if when i release the tab it returns to the far left side of the window.

I understand what you’re saying about Fitt’s Law, but what I am trying to say is that the likelihood of “overshooting” in the case of tabs is pretty remote, because the mouse pointer is usually somewhere in the middle. If you study the behaviour carefully, you’ll see that, when the mouse pointer is in the middle of the tab and you move the tab right against the left edge, the tab stops moving as soon as its left edge hits the left edge of the window, even if you continue to move the mouse pointer to the left. So there is already a margin of tolerance for overshooting built in because of this behaviour.

What I am saying is that if the user drags his tab all the way to the left edge of the window and continues to move his mouse pointer all the way to the left edge of the tab and beyond, even after the tab has already gone as far to the left as it could, then there is a very good chance that he actually does mean to take the tab beyond the left edge of the window.

Same thing on the right hand side, where there is also a built-in margin of tolerance for overshooting, because the mouse pointer will always be more or less in the middle of the tab (unless you deliberately try to click near the right edge of the tab).

But of course maybe some people do throw their mouse all the way to the other side of their screen each time they want to move something to the left or to the right :-).

I expect that the most common tab movement is to move a tab to the far right or far left, in which case there’s a Fitt’s Law argument with regard to the window edges — you can fling the tab to the edge and it will stick.

I certainly could be wrong about those being most common, that’s based only on my own behavior. (When I move tabs, I’m usually moving something to the left edge; with my intent being “I want this to be the only item remaining when I’ve read and closed the rest of the tabs.”)

And it also does not explain why the user cannot take the tab beyond the window’s edges. Vertical precision within the relatively narrow Tab Bar is one thing. Horizontal precision within the width of the Safari window is quite another :).

You’re not likely to accidentally grab a tab too far horizontally, but you’re quite likely to drag a tab too far vertically when you only wanted to move it horizontally.

This is similar to scroll bars — you can start dragging the scroll thumb up or down, and the mouse can wander left or right all the way to the edge of the screen; yet you keep scrolling. Compare to Windows, where a small amount of motion in the other dimension will reset the scroll bar to its original point. It’s quite frustrating, and you end up spending much more energy on precision that doesn’t factor into the action you’re actually trying to take.

The leftmost tab stays restrained to the tab bar if you move it to the right, it’s only if you move it away from the tab bar with your initial movement — that is, toward the left — that it doesn’t. (Logically, this probably “ought to” apply to the rightmost tab too, but maybe only when it’s actually near the window edge.)