The current tab-to-window experience is a little clunky; what I see is: - I click on a tab and start to drag down * A very translucent version of the page appears on my drag cursor, with the tab still being present in the source window - I drop the tab * The window I dragged from flashes, because we removed the tab, and so some other tab comes to the forefront - And finally the window with the new tab appears I think the two starred items can be improved significantly: - When we drag the tab, the drag image should be much more solid near the top, perhaps even completely opaque (but still fading out towards the edges). I would even draw the tab image and put the cursor right on the tab as it moves around, as opposed to anchored to the top left of the image - When we start the drag, we should hide the tab in the source window and switch to whatever tab we would've switched to otherwise. We can do a quick shrinking animation or something of the tab itself. That way when the user drops, there's no flashing because the content switched, just the new window appears. If the drag gets canceled, we can just unhide the tab. Cc'ing Alex, since this sounds like a polish-hard bug.

Oh, also.. with some math, science, and caffeine, we can probably position the new window such that the content appears basically where the user dropped it. We should be able to guess based on the source window, with the assumption that the new window will look the same... this can break given extensions and stuff, but it'll work in most cases.

cc'ing beltzner mano and boriss since I thought they might be working on related things (although the sprint page is currently blank: https://wiki.mozilla.org/Firefox/Sprints/Visual_Affordance_for_Tear_Off_Tabs) Both of Vlad's suggestions are great. Also the behavior in Safari and Chrome is a good reference for ways to improve the experience. The one thing I would add is that unlike Chrome (but similar to Safari), I think drawing browser UI around the tab thumbnail makes sense, since a new window is going to be created. I think Chrome was going for a tearing the tab out of the current window effect, but it is a little ambiguous what will happen when you release the mouse button. Drawing the browser UI is of course problematic given the number of OS themes out there. Is there anyway for us to render the browser chrome and capture an image? It would be pretty cool if the user's customizations showed up in the small representation of the Window. Otherwise we could just create some overly simplified versions for the various major OS themes (and later use them if we get better OS theme detection on XP).

We could, but I think getting the actual chrome there would take this from polish-hard to polish-rocketscience for now :) But, I think having the tab itself, and a native border (e.g. a thin black border on OSX, thicker bluish border on Vista, etc.) would get us 99% of the way there. Might even look better, because if we get the positioning right, the chrome will just magically appear around the tab.

To do anything like this, we need either of these possibilities: * a way to alter the canvas once drawWindow was used, or merge it with some other canvas, the drag api takes an image. * a way to draw an element into a canvas rather than a window (to which i would draw the window, first) All that said, i'm planning on trying to open a popupon each dragover event, rather than using the "preview" api (or mousemove which IIRC isn't cancel-able, once drag starts). Implementing the preview that way, we could alter the "preview" as the mouse moves between the potential drop targets.

(In reply to comment #4) > To do anything like this, we need either of these possibilities: > * a way to alter the canvas once drawWindow was used, or merge it with some > other canvas, the drag api takes an image. Hm, what stops you from doing this right now? DrawWindow is just a normal drawing call; you can keep drawing whatever after that.

This affects all systems. See also bug 483776 which is about changing the mouse cursor when dragging a tab.

This bug's priority relative to the set of other polish bugs is: P2 - Polish issue that is in a secondary interface, occasionally encountered, and is easily identifiable. The current tab tear off UI feels kind of half finished. The only reason I'm not setting this to P1 is that I'm guessing that users aren't tab tearing a whole lot yet, so the issue is more occasional as opposed to constant.

This is mostly a tentative approach, implements a better preview increasing the preview size, adding a black border around the content, and the tab image on top of it. Also tries to hide the tab when detaching. There is actually some problem: - any styling has to be done with canvas, since we just have to pass the image to the dragService (that will then copy it into the native drag object), so we can't theme it easily with css afaict. ifdefs could work though. - Collapsing the tab is fine, but we can't detect all cases, for example once the user exits the tabbar there is no way to tell if they are going to detach or to add a bookmark, or whatever. We can update the visible status only while we are dragging on the tabbar. - The dragging image has a bad alpha gradient on it, that goes from opaque top-left to trasparent down-right. Enn suggested that could be windows API dragging gradient, but i think it should be fixable, for some reason. First of all if i drag any image the trasparency is not bad like that (looks like it could be badly centered on tab previews), second other browsers implementing tab detach preview (like Chrome) can set a pretty visible drag image, without any gradient. I've looked into our windows native dragging code, it looks fine and pretty similar to any dragging code i've found around. This problem exists even in current implementation, on Windows the tab drag preview is hardly visible. I had no luck changing the native dragging code so far, any change did not bring useful gains. Btw, if anyone is willing to give UX suggestions on this that are not rocketscience-polish, that would be cool. This patch implements a preview similar to Chrome's one, ideally we could even print the full window content, overwrite the tabbar and add a single tab, it is just matter to play a bit with canvas.

PS: that said i think just showing the tab on top is much much much cleaner than showing the full window. I tried and it was just bad looking.

I think would even be possible to just show the tab "button" while dragging on tabbar, and append the content preview when dragging out of it, that would give even more feedback about the action. the dragImage should be settable in all drag events (i hope).

See also bug 465186 for getting the positioning right.

I made a tab drag-and-drop animation prototype here: https://bugzilla.mozilla.org/show_bug.cgi?id=455694#c16 I doubt that I will have time to work on this before my internship ends, but I hope this helps with visualizing detach thresholds, animations, and "snapping". We'll have to stop using the current HTML5 drag-and-drop API for the drag image to handle that.

IE9 lets you drag the entire content plus the tab label on top of it, just like a window, including vertical and horizontal scrollbars, but without the window frame and browser UI: http://img189.imageshack.us/img189/989/clipboard01dd.png

The URL section should mention : https://wiki.mozilla.org/Firefox/Projects/Tab_animation ;-)

Oh, and unlike Chrome, videos keep playing while dragging the tear-off-tab around in IE9. Maybe we could do the same using -moz-element on the browser element...

Why doesn't this bug block betaN+? As Alex mentioned, the current tab to window looks like half-finished. And it's far away from IE9 or Chrome or the mockups. http://www.youtube.com/watch?v=epAY_QXaZ-E

Because we have nobody to work on it, and because it's not something which would block the final release of Firefox 4. I would love (love!) to see a contributor step up here and get this done. Big win for users.

Sorry, i dont blame you (Mozilla) for anything. I would love, too...

Build identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b9) Gecko/20100101 Firefox/4.0b9 Dragging a tab from the tab bar outside of the window creates a small thumbnail of the tab. Releasing the button makes the thumbnail slide back to where it came from (creating the impression that the detachment has not worked). However the tab does detach and a new window does open.

(In reply to comment #22) Known issue. Bug 455694 will fix this.

Blocks bug 563540? I think bug 563540 is a special case of "improve tab-to-window experience", and the work to make all this happen would possibly be reduced by considering both issues from the very start, at design stage.

Since I'm fixing the two remaining dependencies and will be doing followup work to polish the experience, including that for bug 563540, I'm assigning this to myself and will close it when the dependencies land.

Fixed by patch in bug 455694. Followups should be marked as depending on that bug.

This appears resolved now in Firefox 8.0b1 and 9.0a2 with a slick tab "sliding" animation. Marking verified.

this is broken in 12.0b1, probably due to 455694 backout

(In reply to eyal gruss (eyaler) from comment #28) > this is broken in 12.0b1, probably due to 455694 backout Can you please file a new bug and mark it dependent on bug 455694? Thanks.

since this is clearly NOT fixed, should it not be resolved as invalid or wontfix?

(In reply to eyal gruss (eyaler) from comment #30) > since this is clearly NOT fixed, should it not be resolved as invalid or > wontfix? It was fixed as per comment 27. If it has recently regressed due to a recent change you should file a new bug.

The patch fixing this has been backed out.