485105 - improve tab-to-window experience

Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)

Reporter

Description

•

16 years ago

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.

Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)

Reporter

Comment 1

•

16 years ago

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.

Alex Faaborg [:faaborg] (Firefox UX)

Comment 2

•

16 years ago

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).

Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)

Reporter

Comment 3

•

16 years ago

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.

Asaf Romano (gone)

Comment 4

•

16 years ago

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.

Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)

Reporter

Comment 5

•

16 years ago

(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.

Mike Beltzner [:beltzner, not reading bugmail]

Comment 7

•

16 years ago

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

OS: Windows Vista → All

Whiteboard: [polish-hard]

Alex Faaborg [:faaborg] (Firefox UX)

Comment 8

•

16 years ago

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.

Whiteboard: [polish-hard] → [polish-hard][polish-interactive][polish-p2]

Marco Bonardo [:mak]

Comment 9

•

15 years ago

Attached patch wip — Details — Splinter Review

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.

Marco Bonardo [:mak]

Comment 10

•

15 years ago

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.

Marco Bonardo [:mak]

Comment 11

•

15 years ago

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).