Last Comment Bug 485105 - improve tab-to-window experience
: improve tab-to-window experience
Status: NEW
[polish-hard][polish-interactive][pol...
: polish
Product: Firefox
Classification: Client Software
Component: Tabbed Browser (show other bugs)
: Trunk
: All All
: -- normal with 16 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
https://wiki.mozilla.org/Firefox/Proj...
: 466196 490031 501543 (view as bug list)
Depends on: 674925 455694 565749 566509
Blocks: 596954 606803
  Show dependency treegraph
 
Reported: 2009-03-24 18:43 PDT by Vladimir Vukicevic [:vlad] [:vladv]
Modified: 2014-08-20 14:36 PDT (History)
44 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
wip (8.17 KB, patch)
2009-09-04 06:25 PDT, Marco Bonardo [::mak]
no flags Details | Diff | Splinter Review

Description Vladimir Vukicevic [:vlad] [:vladv] 2009-03-24 18:43:20 PDT
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.
Comment 1 Vladimir Vukicevic [:vlad] [:vladv] 2009-03-24 18:44:29 PDT
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.
Comment 2 Alex Faaborg [:faaborg] (Firefox UX) 2009-03-24 20:27:29 PDT
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).
Comment 3 Vladimir Vukicevic [:vlad] [:vladv] 2009-03-24 20:38:26 PDT
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.
Comment 4 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2009-03-25 08:35:33 PDT
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.
Comment 5 Vladimir Vukicevic [:vlad] [:vladv] 2009-03-25 19:16:25 PDT
(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.
Comment 6 Mike Beltzner [:beltzner, not reading bugmail] 2009-05-14 08:02:40 PDT
*** Bug 490031 has been marked as a duplicate of this bug. ***
Comment 7 Mike Beltzner [:beltzner, not reading bugmail] 2009-05-14 08:04:18 PDT
This affects all systems. See also bug 483776 which is about changing the mouse cursor when dragging a tab.
Comment 8 Alex Faaborg [:faaborg] (Firefox UX) 2009-06-23 00:06:17 PDT
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.
Comment 9 Marco Bonardo [::mak] 2009-09-04 06:25:00 PDT
Created attachment 398644 [details] [diff] [review]
wip

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.
Comment 10 Marco Bonardo [::mak] 2009-09-04 06:26:58 PDT
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.
Comment 11 Marco Bonardo [::mak] 2009-09-04 08:30:04 PDT
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).
Comment 12 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2009-12-03 15:03:10 PST
See also bug 465186 for getting the positioning right.
Comment 13 Frank Yan (:fryn) 2010-08-03 15:41:59 PDT
*** Bug 501543 has been marked as a duplicate of this bug. ***
Comment 14 Frank Yan (:fryn) 2010-08-07 23:43:24 PDT
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.
Comment 15 Steffen Wilberg 2010-09-16 06:00:31 PDT
*** Bug 466196 has been marked as a duplicate of this bug. ***
Comment 16 Steffen Wilberg 2010-09-16 06:02:15 PDT
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
Comment 17 Nicolas Mandil (:NicolasWeb) 2010-09-16 06:08:45 PDT
The URL section should mention :
https://wiki.mozilla.org/Firefox/Projects/Tab_animation
;-)
Comment 18 Steffen Wilberg 2010-09-16 06:13:22 PDT
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...
Comment 19 Csaba Kozák [:WonderCsabo] 2010-10-07 07:02:44 PDT
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
Comment 20 Mike Beltzner [:beltzner, not reading bugmail] 2010-10-07 07:08:04 PDT
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.
Comment 21 Csaba Kozák [:WonderCsabo] 2010-10-07 07:21:27 PDT
Sorry, i dont blame you (Mozilla) for anything. I would love, too...
Comment 22 George Carstoiu 2011-01-11 05:19:23 PST
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.
Comment 23 Frank Yan (:fryn) 2011-01-11 11:06:56 PST
(In reply to comment #22)

Known issue. Bug 455694 will fix this.
Comment 24 Roman 2011-03-23 05:40:28 PDT
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.
Comment 25 Frank Yan (:fryn) 2011-07-13 00:58:59 PDT
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.
Comment 26 Frank Yan (:fryn) 2011-07-27 03:17:17 PDT
Fixed by patch in bug 455694.
Followups should be marked as depending on that bug.
Comment 27 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-09-30 14:57:39 PDT
This appears resolved now in Firefox 8.0b1 and 9.0a2 with a slick tab "sliding" animation. Marking verified.
Comment 28 eyal gruss (eyaler) 2012-03-20 18:57:42 PDT
this is broken in 12.0b1, probably due to 455694 backout
Comment 29 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-03-26 18:15:02 PDT
(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.
Comment 30 eyal gruss (eyaler) 2012-03-26 18:22:15 PDT
since this is clearly NOT fixed, should it not be resolved as invalid or wontfix?
Comment 31 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-03-26 19:16:41 PDT
(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.
Comment 32 Dão Gottwald [:dao] 2012-03-27 00:47:12 PDT
The patch fixing this has been backed out.

Note You need to log in before you can comment on or make changes to this bug.