Unable to drop tab from tabbar into bookmarks (sidebar, toolbar, Library) from tabbar.

RESOLVED INVALID

Status

()

defect
RESOLVED INVALID
8 years ago
7 years ago

People

(Reporter: tetsuharu, Unassigned)

Tracking

(Depends on 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox8+)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a1) Gecko/20110727 Firefox/8.0a1
Build ID: 20110727031559

Steps to reproduce:

After checked in bug 455694, I drag tab from tabbar.


Actual results:

But it cannot drop tab into bookmark sidebar.
I seem this behavior is regression.


Expected results:

It should be able to drop tab into bookmark sidebar.
Blocks: 455694
OS: Other → Windows 7
Hardware: All → x86
Summary: Unable to drop tab into bookmark sidebar. → Unable to drop tab into bookmark sidebar from tabbar.

Comment 1

8 years ago
Dragging a tab will either rearrange it in the tab bar, move it to another window, or create a new window To bookmark a tab, drag the icon in the address bar to the bookmarks bar.

http://screencast.com/t/6A35nyJvi

Comment 2

8 years ago
When dragging the tab, you are applying direct manipulation to it, just like when dragging a window, so dropping it onto a target besides tab containers doesn't make sense.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
to give you an escape, you can drag the identity part of the locationbar (the favicon and surrounding part) to bookmarks views.
The bug report is well formatted, the behaviour worked before, doesn't now, but is intentionally not being re-implemented; therefore wontfix surely, rather than invalid?

(I've used this feature before and I'm sure others have, but can deal with dragging the identity button instead)
Resolution: INVALID → WONTFIX

Updated

8 years ago
Keywords: regression

Updated

8 years ago
Duplicate of this bug: 674833
Is it worth getting the UX team in to evaluate whether this should be restored? I suspect there are going to be quite a few dupes...
don't think so, this has been discussed in the past already, and the current solution is what everybody agreed with.
Depends on: 674732
This would a major complaint when Firefox 8 releases. There should be a better indication to users that the identity box can be dragged to a bookmark.
(In reply to comment #8)
> This would a major complaint when Firefox 8 releases. There should be a
> better indication to users that the identity box can be dragged to a
> bookmark.

There will be blog posts and whistles about the change, this won't be sufficient obviously, but it's hard to give indication something is draggable to do a certain action.  Adding stuff to the identity button tooltip doesn't seem sensible, since that contains security and far more important information.
If you have ideas on how to improve that, you may file enhancement bugs with them.

Regarding the fact we may have a major complain, complains are usual for any change, good or bad it is, if it breaks an habit.  There is no magic way to avoid it, if not by blocking improvements, that would be an even worse loss.  It breaks my habits too, since I often drag tabs to bookmarks, so I'm not just talking from a "developers don't care" point of view, I accept it since the improvement is pretty clear, the loss has a workaround I just have to get used to.
You can now do this by holding down the ctrl key (opt key on OS X) while beginning a tab drag.

I'm leaving this as WONTFIX, because we are not going to implement this for drags without modifier keys.

Comment 11

8 years ago
Can't we re-enable this feature only on the favicon of the tab, with an exception for Application tabs? This won't break the current behaviour and use the logic of the locationbar.
This way we solve the cumbersome switch to tab before bookmarking since we can grab an inactive favicon to place it in the bookmarks bar.
Duplicate of this bug: 675601

Updated

8 years ago
Duplicate of this bug: 675601

Comment 14

8 years ago
@Frank Yan

It seems that the devs have this not thought to the end.

Regarding tab move operations for extensions how Tabgroubsmanager for example. The drag operations with the favicon or with the CTRL Key produces only a copy of the tab and no movement is possible anymore. And this is not acceptable.

Comment 15

8 years ago
(In reply to neb1236 from comment #11)
> Can't we re-enable this feature only on the favicon of the tab, with an
> exception for Application tabs? This won't break the current behaviour and
> use the logic of the locationbar.
> This way we solve the cumbersome switch to tab before bookmarking since we
> can grab an inactive favicon to place it in the bookmarks bar.

I for one would like this, mind filing it as a new bug?

Updated

8 years ago
Duplicate of this bug: 680677
Duplicate of this bug: 680839

Comment 18

8 years ago
Requiring Ctrl+  on the drag tab to bookmark will conflict and destroy "Multiple Tab Handler" extension [https://addons.mozilla.org/firefox/addon/multiple-tab-handler/] and any other extension that has selection ability on tabs. Unacceptable like in #c14.  Also with tabs reduced to favicon size or smaller there is no such thing as favicon only portion of a tab #c15.

Updated

8 years ago
Blocks: 681353

Comment 19

8 years ago
(In reply to alex_mayorga from comment #15)
> (In reply to neb1236 from comment #11)
> > Can't we re-enable this feature only on the favicon of the tab, with an
> > exception for Application tabs? This won't break the current behaviour and
> > use the logic of the locationbar.
> > This way we solve the cumbersome switch to tab before bookmarking since we
> > can grab an inactive favicon to place it in the bookmarks bar.
> 
> I for one would like this, mind filing it as a new bug?

Done, filed bug 681353

Updated

8 years ago
Duplicate of this bug: 681368
Duplicate of this bug: 681470

Comment 22

8 years ago
There is a way to drag from bookmarks bar to tabbar
So there should be a way reverse - like :

If i drag tab and got mouse over bookmarks (bookmarks bar under urlbar or sidebar) it's possible to drop, else there is visible new window
Why can't we restore the old behaviour? Is there some technical difficulty?
I don't see what is the improvement of blocking this feature.
There is some discussion ongoing on this (see also m.d.a.f.), it should be feasible (most likely would first be better to first use the d&d api), the issue was mostly regarding what you are interacting with and if makes sense to drag it to certain points, but this still remains as a functionality regression for most users.
Let's reopen for now while the discussion continues.
Ideally if we may still drop and resnap the tab to its original position would be fine for
Status: RESOLVED → REOPENED
Depends on: 674925
Ever confirmed: true
Resolution: WONTFIX → ---
Summary: Unable to drop tab into bookmark sidebar from tabbar. → Unable to drop tab from tabbar into bookmarks (sidebar, toolbar, Library) from tabbar.

Comment 25

8 years ago
i think event based d&d should resolve this problem

default action - there is visible window (like it is right now)

if mouse drag window over sidebar - it is possible to drop to sidebar

else if mouse drag window over bookmarks - it is possible to drop to bookmarks

else if mouse drag window over Library - it is possible to drop to Library

and this should resolve this issue

Comment 26

8 years ago
(In reply to Marco Bonardo [:mak] from comment #24)
> There is some discussion ongoing on this[...]

Do you think this discussion might also look kindly upon re-introducing tab duplication? In particular to work towards fixing Bug 676686 and Bug 675438
(In reply to Marco Bonardo [:mak] from comment #24)
> There is some discussion ongoing on this (see also m.d.a.f.), it should be
> feasible (most likely would first be better to first use the d&d api), the
> issue was mostly regarding what you are interacting with and if makes sense
> to drag it to certain points, but this still remains as a functionality
> regression for most users.
> Let's reopen for now while the discussion continues.
> Ideally if we may still drop and resnap the tab to its original position
> would be fine for

Based on the discussion in d.a.f, it's clear that we won't be implementing this or accepting fixes for it.
https://groups.google.com/forum/#!topic/mozilla.dev.apps.firefox/Mi7i_86Yf-A/discussion
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → WONTFIX

Updated

8 years ago
Duplicate of this bug: 675444
(In reply to Frank Yan [:fryn] from comment #27)
> Based on the discussion in d.a.f, it's clear that we won't be implementing
> this or accepting fixes for it.

Honestly, I don't see that decision in the discussion.
Btw. as a data point, searching bookmarks in input.mozilla.org reports this as the outstanding issue.

Updated

8 years ago
Duplicate of this bug: 683896

Comment 31

8 years ago
Considering this is a regression of functionality. Why is it so easily being pushed aside without any outrage from both the QA and UX teams?

If this isn't going to fixed then can we make it so that every time someone does try to drag a tab on to the bookmark toolbar, a small paperclip appears and instructs them to try doing with the Ctrl key pressed?

Comment 32

8 years ago
(In reply to Harsh86 from comment #31)
> If this isn't going to fixed then can we make it so that every time someone
> does try to drag a tab on to the bookmark toolbar, a small paperclip appears
> and instructs them to try doing with the Ctrl key pressed?

Clippy is the abomination that shall never be resurrected!
(In reply to Marco Bonardo [:mak] (Away 6-18 Sept.) from comment #29)
> (In reply to Frank Yan [:fryn] from comment #27)
> > Based on the discussion in d.a.f, it's clear that we won't be implementing
> > this or accepting fixes for it.
> 
> Honestly, I don't see that decision in the discussion.
> Btw. as a data point, searching bookmarks in input.mozilla.org reports this
> as the outstanding issue.

Shaver (Firefox module owner) said he'd be ok with the bookmarks toolbar accepting dragged tabs.
No longer blocks: 681353
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
OS: Windows 7 → All
Hardware: x86 → All

Updated

8 years ago

Updated

8 years ago
Duplicate of this bug: 690254

Comment 36

8 years ago
(In reply to David McRitchie from comment #18)
> Requiring Ctrl+  on the drag tab to bookmark will conflict and destroy
> "Multiple Tab Handler" extension
> [https://addons.mozilla.org/firefox/addon/multiple-tab-handler/] and any
> other extension that has selection ability on tabs. Unacceptable like in
> #c14.  Also with tabs reduced to favicon size or smaller there is no such
> thing as favicon only portion of a tab #c15.

It also destroy Tab Mix Plus, I think the best Firefox should restore tab feature to Firefox 7.0, and target other feature that better than Tab move detach animation: https://wiki.mozilla.org/Firefox/Features/Tab_move_detach_animations

I suggest Tab multi select: https://wiki.mozilla.org/Firefox/Projects/Tab_Multi-Selection/Design
Everything have in Multi Tab Handler.

Comment 37

8 years ago
Not sure if this has been brought up elsewhere; I haven't seen it mentioned. Tabs are generally several times larger than favicons or the bookmark star. Requiring users to click and drag the favicon or use a second hand to hold ctrl while dragging may present difficulties to users with accessibility issues.
Patch in bug 455694 was backed out.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago7 years ago
Keywords: regression
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.