589401 - drag a tab into the TabCandy button and have the TabCandy display open so I can drop the tab on a tab group (spring-loaded TabCandy button?)

Status: RESOLVED WONTFIX

(Firefox Graveyard :: Panorama, enhancement)

Description

[Dave Miller [:justdave]]

A lot of times when I open a link from another app, it opens into whatever tab group was active at the time.  If it's something I want to keep open for a bit, I'd often like to move it to a more appropriate tab group.  Right now to do that you have to a) click the TabCandy button, b) find the window you were just looking at, c) drag it where you want, d) click on it to make it active again.

It would be awesome if I could drag the tab onto the TabCandy button, have the window automatically switch to the Tab Candy view with my drag still active, and then I can drop the tab right into the group I want it in (and the tab would automatically become active again, closing the TabCandy view, but in the right group).  Think of it like the spring-loaded folders in the Mac Finder. :)

Comment 1

[Michael Yoshitaka Erlewine [:mitcho]]

Punting to the future. This would also be a good place for an add-on to step in.

Comment 2

[Adam]

Attachment: WIP: Adds DND handler, test.

The test is fairly simple at this point, only testing tabs.

The patch itself only has a few issues:

1. If you drag into and then back out of Panorama (by dragging over the Panorama button) with a tab, the attempt to unhide the TabItem in Panorama doesn't work correctly and upon reentering Panorama it reappears with a black canvas.
2. The handler currently doesn't distinguish between positions within a group.
3. Dropping multiple items should probably not select one, but stay in Panorama to let the user pick; if not, then at least it should select the first of the dropped items (currently selects the last).
4. I suspect that it should be reduced to only handling the tab and text flavors, since anything else (eg, Places items) include that in their data.

Interested in any feedback, but particularly on a better way to handle the TabItem hiding issue and general ideas for making this patch achieve drag feedback that's consistent with what's already in Panorama.

Comment 3

[Tim Taubert [:ttaubert] (inactive)]

Thanks for doing this! This look like a pretty good start though I would advise you to better start this prototyped as an add-on. That's a pretty good way to get an overview over features that aren't well specified yet and it's easy for everyone to install, try and get inspired.

Some hints:

* Bug 455694 is soon to be implemented and tab drag/drop is going to be very different from now. This will be the result: https://bug455694.bugzilla.mozilla.org/attachment.cgi?id=463283
* When the Panorama button is on the same position on the toolbar as it is when Panorama is opened it just keeps toggling while hovering the button.
* Dropping the ghost in a group does not work for me (on Linux at least).
* If the tabItem is black after unhiding you could call TabItems.update(xulTab) to let it update again.
* Maybe you should just replace the dragged tab with the tabItem itself? That would handle everything automatically. I guess dragging the tab out of Panorama is pretty useless, so you could cancel the drag at this point?

Comment 4

[Adam]

Thanks for the feedback, Tim.  Per your suggestion, I've created a prototype add-on for this bug.  

The git repository is at https://github.com/hobophobe/bug589401 and contains an XPI alongside the source.

See the README there, but briefly the current version:

* Doesn't support dragging back out of Panorama; need to decide how to handle the case where the enter and exit buttons overlap in screen coordinates (as per comment 3).

* Doesn't support dragging tabs between windows.  This would probably require moving the tab to the new window _during_ the drag, and I'm not yet sure if that would invalidate the transfer data.

Comment 5

[Ethan Sisson]

(In reply to comment #3)
> * Maybe you should just replace the dragged tab with the tabItem itself?
> That would handle everything automatically. I guess dragging the tab out of
> Panorama is pretty useless, so you could cancel the drag at this point?

Do you mean you think it's worth it not to support dragging back out of Panorama at all? I think it's important to support this as a form of undo (i.e. "Oops, I didn't mean to drag that tab to the Panorama button. Let's take it back out."). Granted, in that situation you could just drop it back into it's current tab group, but many users' first try will be to reverse the steps they just performed.

(In reply to comment #4)
> * Doesn't support dragging tabs between windows.  This would probably
> require moving the tab to the new window _during_ the drag, and I'm not yet
> sure if that would invalidate the transfer data.

Related: Bug 594441

Comment 6

[Adam]

In using the extension I've accidentally dragged tabs over the Panorama button a lot (trying to drag tabs between windows), and it meant restarting the process.

Once Panorama has access to the tab groups for all windows, dragging back out won't be strictly needed.

One alternative is hiding when dragging out of the iframe.  The discoverability isn't good: users would still try to drag over the exit button.

For dragging over the buttons, the problem is handling the dragover listener for the enter/exit buttons.  That's exacerbated by the fact we can't depend on a listener on the drag source (because the drag may originate outside the browser), and so we can't know if the previous drag has ended.

The easiest fix for dragging over the buttons would be a timeout that restores the listener, but that's ugly and the length is arbitrary: if it's too long, the user will think it's broken, if it's too short then they'll still see bouncing (toggling in and out).

Comment 7

[Tim Taubert [:ttaubert] (inactive)]

We're not going to address this with Panorama being slated for removal.

Comment 8

[Roman]

Bug for Panorama removal: bug 836758