675444 - It should be "drag tab" instead of "CTRL + drag tab" if we drop it to bookmarks/bookmarks panel

Status: RESOLVED DUPLICATE of bug 674723

(Firefox :: Bookmarks & History, defect)

Description

[Joe Wilson]

Why do we now need to hold CTRL if we drag a tab to Bookmarks/Bookmarks Toolbar?
Earlier - we never needed to hold CTRL for that case. We held CTRL in the single case we drag-n-drop a tab: only when the tab was dragged to the tab bar (to duplicate tab).

Comment 1

[Frank Yan (:fryn)]

I already explained this several times in bug 455694.
Specifically, you can read bug 455694 comment 111.
Please stop filing extremely similar bugs regarding this decision.

Comment 2

[Joe Wilson]

But that absolutely doesn't make any sense!

Marco, do you realize that your decision not to support the behavior that users got used to for the years is kinda destructive towards users? You want to brake our habits just because you have "another ingenious idea"? Why?
Does this feature have any NEGATIVE EFFECT to anyone? No, and I won't ever believe in the story that "many users may ACCIDENTALLY HOLD CTRL" as it's just a thing you CAN'T DO NOT ON PURPOSE.

Comment 3

[Timur Fayzullin]

bug 455694 comment 111:
"as previously discussed this will be the wanted behavior, once tabs become more like "window" entities, doesn't make sense to add a window to a toolbar. You can still drag the favicon from the locationbar, usually you will drag the tab for the current visible page, so that should not be any harder."

==> !!!  Marco Bonardo [:mak], Frank Yan [:fryn]  !!! <==

Why don't make this function optional? I don't need this "GREAT ANIMATION" while I'm dragging the tab. It's more comfortable to me to see the arrow, but not the jumping tabs to the left, to the right, to the left and so on.

But the main reason to make its optional - it's the destroy of the drag&drop function! It's very uncomfortable to drag the favicon from location bar. Why did you break down function that has been used for many years in your browser and in the others?! It's very lamentably...

Comment 4

[Lozzy]

(In reply to comment #1)
> I already explained this several times in bug 455694.
> Specifically, you can read bug 455694 comment 111.
> Please stop filing extremely similar bugs regarding this decision.

In no ambiguous terms, your explanation was unsatisfactory and insufficient justification for making these changes. So far, you've done nothing to give us a proper explanation of why you're breaking these interactions, which require the CTRL key to be pressed. It's an explicit indication that my intention is atypical.

Like Joe said, you simply can't argue that these interactions can happen accidentally. I don't understand why you're deliberately breaking established usage patterns which have no negative effects on uninitiated users.

Comment 5

[Matthew Turnbull [Bluefang]]

I've made a couple observations:

* When dragging in the (originating) tab bar, the tab retains its appearance of a tab

* When dragged outside of the tab bar, it changes to a window preview with a title bar at the top. Dropping it will detach it to a new window

* Dragging the tab onto the tab bar of another window hides the preview so only the title is visible. However, this is different from the first point in that it does not have the appearance of a tab.

This seems contrary to all of the arguments I've seen for the drag animations are that it makes dragging more semantic and contextual. IMHO this has only served to fracture the pre-existing semantics and contexts even further.

* Previously, there was 1 visual representation of a dragged tab. Now there are 3 (4 with +CTRL).

* Previously, the dragged tab interacted in a contextually correct manor, and as expected, with all drop locations. Now it only responds to 1 (2 if you count tear-off).

Add +CTRL and you've got a whole new set of actions, and while consistent, they don't behave contextually or semantically in a way that always makes sense.

* It uses the old visuals on the tab bar (though it uses the favicon instead of a preview).

* Duplicating a tab no longer duplicates it. It opens a new tab and loads the content. I see no meaningful rationalization for this change in behavior, and reloading the content seems like a waste of compute power and network resources.

* 'Duplicating' one tab onto another tab replaces it rather than opening the 'duplicate' in a new tab next to it. I could really go either way on this.

And, of course there are usability issues with all of these changes

* Having tabs slide around is visually jarring. It's been a few days and I still haven't gotten used to it. Not to mention tht it now gives you a 'moving' drop target, and it makes it difficult to read the tab names while dragging.

* You can use the location bar identity block to bookmark/'duplicate' a tab, but it is a much smaller grab target, it is visually disjoint from the tab (which is highlighted in the UI), and it is not discoverable.



I think that there are a few simple things that can be done to improve this situation.

* Unify the dragged tab appearance. If you want it to look like a tab, keep it looking like a tab no matter where you drag it. Changing it visually is jarring and distracting.

* When holding CTRL, have the dragged item be a ghost of the complete tab, rather than just the favicon. That gives a much better impression that the tab is being copied rather than moved. And when moving it around on the tab bar, use the new animation. Again, unify the visual appearance.

* Make the drag animation on the tab bar optional (just the animation, not the behavior)

* Restore the old behavior and have dragged tabs respect all drop areas in a contextually correct manor. Not respecting drop targets fractures the flow of the UI and leaves the user wondering why it doesn't work (especially in this case where it is removing pre-existing behavior).

From a platform consistency perspective, if I can drag a file/folder into Firefox and drop it in the tab bar, location bar, or bookmark menu/toolbar, why should I not be able to do the same with a tab (without involving the keyboard)?

And from a competitive standpoint, in IE9 you can drag tabs to the Favorites bar (if you have more than one tab open). From what I've read online, this looks like a new feature. So why is Firefox removing it?

And I don't see any issue with just having the tab re-appear in its original location when you preform a drop-action that does not physically move the tab.



I do not see why these animations dictate removing or changing established browser functionality/behavior/usability, especially when they largely make no sense contextually or semantically. This is nothing but pushing eye-candy for the sake of eye-candy, while sacrificing functionality/behavior/usability. And I've always said I'd prefer functionality over eye-candy.

Yes, I recall there was a fair amount of noise when the GO button was first moved, and when tab-tearing was first introduced. Those did peter out after a few months (we still do see complains at MozillaZine). Those were either cosmetic changes, or adding new functionality with minimal impact to the existing. But this is a much more radical change, in that it either removes or largely redefines how tabs are interacted with. And given that Firefox is a tabbed browser, that's kind of messing with your bread and butter.

This whole situation reeks of a group defending a [bad] decision, not wanting to back-pedal/cave under negative backlash, or of an individual fanatically dedicated to the cause without heed to its impact on the product and its users.

All I can say is that, as a volunteer in the support community, I do not look forward to when this sees a larger audience.

Comment 6

[Joe Wilson]

Don't WONTFIX this without argumentation.

Comment 7

[James May [:fowl2]]

I just picked up this bug in today's nightly and would just like to add that while I can kinda understand having to hold CTRL, I can't understand why CTRL has to be held before starting the drag for it to have any effect.

This is different from every other app on the platform, which allow you to "preview" the effects of keyboard modifiers by starting a drag and then trying different modifiers. For drag a file in Windows Explorer then add CTRL, SHIFT or alt, or any combination and observe both the icon and textual description of the target change. (offtopic: we're missing the nt6 drag'n'drop tooltip)

Comment 8

[James May [:fowl2]]

Ooops, just noticed bug 675438, sorry.

Comment 9

[Joe Wilson]

Confirm this bug, as here http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/322ee2ffce987fe0 Dietrich Ayala and Gervase Markham supported my idea.

Comment 10

[Gervase Markham [:gerv]]

If dragging a tab to the bookmarks bar used to add it to the bar, and now does nothing at all, I consider that a functional regression. Unless there is some important technical reason why we can't continue to support this ability, we should do so. We should not break people's habits unnecessarily. 

Gerv

Comment 11

[Marco Bonardo [:mak]]

can we keep things in a single bug and duplicate this to bug 674723? Any reason to keep it separated?

Comment 12

[Art K]

<RANT>
A latecomer to this discussion but I what I see is the arrogance of someone trying to redefine basic Windows behavior:

   Drag moves. 
   Cntl+drag duplicates. 
   The cursor changes dynamically to reflect the current key presses. 
   Period!

The basic tenet of Windows is to standardize common functions and behavior across ALL apps - not facilitate random behavior according to a whim of a developer. Basic Windows behavior is akin to physical laws: They exist. You can't wish or legislate them away. One has to accept reality. To implement behavior contrary to the basic environment is to invite confusion and frustration for the user. NOT a good thing.

Something is seriously wrong with Mozilla development if one person can unilaterally force a change in something as basic as drag and drop behavior.

I am continually being bemused by the waste of resources chasing rainbows trying to emulate Chrome or Safari. Chrome and Safari are useless for anything other than basic simple-minded surfing and their GUIs suck! (to put it bluntly!) As has been stated earlier, animated "sliding" tabs are jarring, confusing and a total waste of manpower and processor resources. The simple arrow denoting where a tab would be dropped is quite definitive and sufficient. If it ain't broke - don't fix it!

Instead of chasing fluff, how about working on fixing real bugs such as: plugging memory leaks, fixing run away (100%) CPU "trips" (which show that FF only uses one core even when multiple cores are available), frequent crashes, etc.
</RANT>