471499 - specification for valid drop targets for tab strip drag to tear off / detach tabs

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect, P1)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

The goal here is:
 
 - to allow users to drag tabs "off" the tabstrip to detach them and create new windows
 - to not interfere with normal tab drag and drop operations such as:
 --- drag to re-order within the tab strip (see bug 465184, bug 465346)
 --- drag to bookmark toolbar to create bookmark (see bug 465332)
 --- drag to <input> area in content to copy URL (see bug 467376)
 --- accidental drags (see bug 465184, bug 465346)

I recommend the following specification:

 - dragging to toolbar will NOT result in detach
 - dragging within tabstrip will NOT result in detach
 - dragging more than 50% "off" tabstrip (downwards onto content, sideways out of the window) will detach
 - dragging to a <input> element will NOT result in detach

see http://pastebin.mozilla.org/601924 for a diagram

Comment 1

[Alfred Kayser]

I would make this list more granular and defined. 

Dragging into content resulting into a detach new window is just not logical. 
One would argue that when window is maximized, there is no other way to detach, but one can still drag to the window titlebar and frame to achieve the effect.
Dragging into content just causes to many surprises for too many people.
A more logical behavior would be to raise the dragged tab (when it is non-active/background) to the foreground).

The full list in order of matching priority:
0. It is only a drag when moved more than a few pixels...
1. dragging to tab bar --> re-order tabs
2. dragging to bookmark toolbar --> create bookmark
3. dragging outside window --> detach in new window
4. dragging tab into <input> --> no action (or insert URL?)
5. dragging active tab in content --> no action
6. dragging non-active tab in content --> make tab active
7. dragging into other window elements (frame, window titlebar) --> detach in new window
8. dragging into other toolbars/menubars: make tab the active tab?

Comment 2

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #1)

> 1. dragging to tab bar --> re-order tabs
> 2. dragging to bookmark toolbar --> create bookmark
> 3. dragging outside window --> detach in new window

I think it would be better to copy the tab. People can always close the original tab

> 4. dragging tab into <input> --> no action (or insert URL?)

Insert URL

> 5. dragging active tab in content --> no action

I think this should reload the tab

> 6. dragging non-active tab in content --> make tab active

Also reload (preferably without making it active)

> 7. dragging into other window elements (frame, window titlebar) --> detach in
> new window

I think this should copy the tab

> 8. dragging into other toolbars/menubars: make tab the active tab?

This should do nothing

Comment 3

[Mardeg]

Where is Fitt's law here? I think only dragging to a corner of the screen should detach tabs in maximised windows, which would permit a MEGA indicator before you release the mouse button that is about to happen. CSS transitions to pulsate the opacity in and out or something.

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #1)
> Dragging into content resulting into a detach new window is just not logical. 
> One would argue that when window is maximized, there is no other way to detach,
> but one can still drag to the window titlebar and frame to achieve the effect.
> Dragging into content just causes to many surprises for too many people.

Back that assertion up, please? Dragging off the tab strip into the content area to create a new tab is safari-and-chrome-parity, feature wise. Pulling an object "off" of a location to create a new window seems eminently logical.

A computer's desktop is metaphorical representations of objects. The "tab" object represents a page, not a URL. The default result of manipulating that object should be the manipulation of that page. Presently, moving the tab side to side within the tab strip moves that object within that frame of reference. This specification proposes that when the tab object is pulled from the tab strip, we tear off the tab. If, however, the drop target is something which could reasonably be expected to react differently to dropping a "page" on it, we should do that (ie: create a bookmark, enter the page address into a text area)

> A more logical behavior would be to raise the dragged tab (when it is
> non-active/background) to the foreground).

We currently raise a tab to the foreground on mouseDown, so we're doing that.

> The full list in order of matching priority:
> 0. It is only a drag when moved more than a few pixels...
> 1. dragging to tab bar --> re-order tabs
> 2. dragging to bookmark toolbar --> create bookmark
> 3. dragging outside window --> detach in new window

This all matches the existing specification.

> 4. dragging tab into <input> --> no action (or insert URL?)

Between those two options, I don't see why we wouldn't maintain the existing functionality. No need to break users for no reason.

> 5. dragging active tab in content --> no action
> 6. dragging non-active tab in content --> make tab active

These make no sense at all. They're basically NO-OPs from where we are now. The "halfway" precaution prevents accidental drags.

> 7. dragging into other window elements (frame, window titlebar) --> detach in
> new window

Frame is fine, window titlebar is fine, I guess, just seems more complex than it needs to be.

> 8. dragging into other toolbars/menubars: make tab the active tab?

Yes, on mouseDown, as currently exists. Not only that, though, we should show a "you can't drop that there" indication, either by animating the tab "scooting"  back to where it was before, or with a cursor modification.

(In reply to comment #2)
> > 1. dragging to tab bar --> re-order tabs
> > 2. dragging to bookmark toolbar --> create bookmark
> > 3. dragging outside window --> detach in new window
> 
> I think it would be better to copy the tab. People can always close the
> original tab

No, no, no. Please do not scope creep this bug. We're not changing the way detachable tabs work.

> > 5. dragging active tab in content --> no action
> I think this should reload the tab

Disagree. Users do not think of the "content area" as a handler or area that can take a tab object and do something interesting with it. They see that as the content of the tab itself.

(In reply to comment #3)
> Where is Fitt's law here? I think only dragging to a corner of the screen
> should detach tabs in maximised windows, which would permit a MEGA indicator
> before you release the mouse button that is about to happen. CSS transitions to
> pulsate the opacity in and out or something.

Fitt's law is in effect if the browser frame is considered a valid detach location. You can throw the mouse to the corner and the tab will detach.

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

I should note that in all cases better feedback in terms of displaying when a tab will and won't be detached is needed. That would be a different bug, though - I think Mano knows the number?

Comment 6

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #4)

> (In reply to comment #2)
> > > 1. dragging to tab bar --> re-order tabs
> > > 2. dragging to bookmark toolbar --> create bookmark
> > > 3. dragging outside window --> detach in new window
> > 
> > I think it would be better to copy the tab. People can always close the
> > original tab
> 
> No, no, no. Please do not scope creep this bug. We're not changing the way
> detachable tabs work.

Out of frustration

> 
> > > 5. dragging active tab in content --> no action
> > I think this should reload the tab
> 
> Disagree. Users do not think of the "content area" as a handler or area that
> can take a tab object and do something interesting with it. They see that as
> the content of the tab itself.
>

This will change (regress) the function we once had in Firefox 3.0. Dragging a tab into the page reloads the page.

Comment 7

[Alex Faaborg [:faaborg] (Firefox UX)]

>I recommend the following specification:
>
> - dragging to toolbar will NOT result in detach
> - dragging within tabstrip will NOT result in detach
> - dragging more than 50% "off" tabstrip (downwards onto content, sideways out
>of the window) will detach
> - dragging to a <input> element will NOT result in detach

I think Safari pretty much has this interaction perfect.  Their implementation is the same in that dragging to the chrome of the browser will not result in a detach, but they are changing the appearance of what you are dragging to give you constant visual feedback on what will happen when you let go of the item that you are dragging.  When you are dragging over the top part of chrome (tab strip, bookmarks toolbar, main toolbar, location bar, title bar, etc), the item being dragged continues to look like a tab.  Once you drag outside of the top area of chrome, the item turns into a small image of a window.  This is very direct manipulation based, and doesn't result in any surprises.

> - dragging to a <input> element will NOT result in detach

I think we should allow for this behavior by letting the user drag the text of the location bar into an input element.  I'm worried that the result of the drag operation will seem random as you pull a tab down, depending on what is in the content area (currently by content area is a large text field, but I don't have any intention of dragging a tab into it).  Also, when you drag the text of the location bar (at least on OS X), what you see is the literal text being dragged, as opposed to having to either know (or assume) what is about to happen.

Comment 8

[Ria Klaassen (not reading all bugmail)]

In Firefox 3 you can have several tabs open with quickly changing contents (forums, news etc.) and while switching tabs you can drag it down a bit and then it quickly reloads. I just checked Google Chrome but this browser doesn't have it.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #7)
> is the same in that dragging to the chrome of the browser will not result in a
> detach, but they are changing the appearance of what you are dragging to give

See comment 5 where I mention that in all cases we need to improve the visual feedback :)

> I think we should allow for this behavior by letting the user drag the text of
> the location bar into an input element.  I'm worried that the result of the

We do that as well. Pages with large <input> elements right near the top are pretty few and far between, really, so I don't forsee this as a big problem. If it turns out to be, we can revisit the decision.

Again, either way, we'd want to pretty much instantly change the visual feedback to indicate what's going to happen.

Comment 10

[Alex Faaborg [:faaborg] (Firefox UX)]

>Pages with large <input> elements right near the top are
>pretty few and far between, really, so I don't forsee this as a big problem.

Certainly not a big problem, but since we have a mechanism for intentional drags to text areas, why not make accidental tab drag operations 0 (instead of maybe a few hundred amongst our hundreds of millions of users).  Also, having a tab with its full content area morph into a URL seems, odd.

Comment 11

[Asaf Romano (gone)]

We cannot implement "live" feedback unless neil says otherwise.

Comment 12

[IU]

My only argument, so as to not spam this bug to death, is that it sure would be nice if dragging to the filesystem (e.g. explorer) could remain a shortcut creating operation, as I'm sure the same argument used for preserving such functionality for bookmarking could be applied here.  Then only dragging the tab downward and releasing within the content area (minus input boxes) of the same window would validly detach.

This would also preserve cross-window drags for loading a tab in another window or application (e.g. Firefox --> IE).

Comment 13

[Asaf Romano (gone)]

Attachment: patch

The implemented behavior:
 1. Dropping on any text field (within or outside the window) -> "paste". For now, I didn't implement the "top area" gesture mostly because this involves non-trivial back-end changes. We can do that later if that's really necessary
 2. Dropping anywhere else outside the browser window -> detach
 3. Dropping on the content area, by the height of a tab off the tabbar -> nothing
 3. Dropping anywhere else within the content area ("down enough" and not on a text field) -> detach
 4. Dropping on chorme element which handled URLs in Firefox 3 -> same as in Firefox 3
 5. Dropping on the tabbar -> same as in Firefox 3
 6. Dropping anywhere else on the browser chrome -> nothing.

I think we should land this and see how it feels.

Comment 14

[tabmix.onemen]

> var contentAreaDNDObserver = {
>   onDrop: function (aEvent, aXferData, aDragSession)
>     {
>       if (aEvent.getPreventDefault())
>         return;
> 
>-      var url = transferUtils.retrieveURLFromData(aXferData.data, >aXferData.flavour.contentType);
>+      var dragType = aXferData.flavour.contentType;
>+      var dragData = aXferData.data;
>+      if (dragType == "application/x-moz-tabbrowser-tab") {
>+        // If the tab was dragged from some other tabbaer, its own dragend
>+        // handler will take care of detaching teh tab
>+        if (dragData instanceof XULElement && dragData.localName == "tab" &&

if tab was dragged from some other tabbaer why then its logical that the user want the tab to move to the target window and not to 3rd window  Bug 470189

also, if the user hold Ctrl while drop the tab i think that we need to copy the tab, not detach it.
if the dragged tab drop on its own tabbar while Ctrl is pressed then we create duplicate in the same window, it's just make sense that we apply the same behavior and copy the tab to new window when Ctrl is pressed and tab drop on content

Comment 15

[eyal gruss]

(In reply to comment #14)

> also, if the user hold Ctrl while drop the tab i think that we need to copy the
> tab, not detach it.
> if the dragged tab drop on its own tabbar while Ctrl is pressed then we create
> duplicate in the same window, it's just make sense that we apply the same
> behavior and copy the tab to new window when Ctrl is pressed and tab drop on
> content

i filed bug 472024 for this

Comment 16

[Asaf Romano (gone)]

(In reply to comment #14)
> > var contentAreaDNDObserver = {
> >   onDrop: function (aEvent, aXferData, aDragSession)
> >     {
> >       if (aEvent.getPreventDefault())
> >         return;
> > 
> >-      var url = transferUtils.retrieveURLFromData(aXferData.data, >aXferData.flavour.contentType);
> >+      var dragType = aXferData.flavour.contentType;
> >+      var dragData = aXferData.data;
> >+      if (dragType == "application/x-moz-tabbrowser-tab") {
> >+        // If the tab was dragged from some other tabbaer, its own dragend
> >+        // handler will take care of detaching teh tab
> >+        if (dragData instanceof XULElement && dragData.localName == "tab" &&
> 
> if tab was dragged from some other tabbaer why then its logical that the user
> want the tab to move to the target window and not to 3rd window  Bug 470189
> 

Maybe, It feels to me that when there are few browser window which are overlapping each other, dropping a tab on a content area rather than say, on the desktop, would usually be for one's comfort rather than that logic.

> also, if the user hold Ctrl while drop the tab i think that we need to copy the
> tab, not detach it.
> if the dragged tab drop on its own tabbar while Ctrl is pressed then we create
> duplicate in the same window, it's just make sense that we apply the same
> behavior and copy the tab to new window when Ctrl is pressed and tab drop on
> content

File a bug. We probably won't implement that in 3. for a couple of reasons:
1. The dragend event does not contain information about the pressed modifiers.
2. Support for tab duplicating is not as good as the support for tab-"moving". It relies heavily on session store.
3. Accessibility - we cannot add yet another context menu item for this operation this late in the game

We can live with the third issue for now, I guess. The solution for the first one should be easy, though I cannot tell how would it make sense HTML5-spec-wise. As for the second one, I really don't know, i guess it depends on how do we handle tab-duplicating now, when private browsing is turned on.

Comment 17

[tabmix.onemen]

> 1. The dragend event does not contain information about the pressed modifiers.

but contentAreaDNDObserver.onDrop have the information

Comment 18

[Asaf Romano (gone)]

...which is not called when you drop the tab outside of the browser window.

Comment 21

[Nochum Sossonko [:Natch]]

mano I don't think it will be possible to fix the escape handling in bug 465608, see bug 471848.

Comment 22

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 357493 [details] [diff] [review]
patch

For people looking to try this out, I ran a tryserver build, it's available here for the next 30 days (until 2009-02-19):

https://build.mozilla.org/tryserver-builds/2009-01-19_07:[e-mail]-bug471499/

> The implemented behavior:
>  1. Dropping on any text field (within or outside the window) -> "paste". For
> now, I didn't implement the "top area" gesture mostly because this involves
> non-trivial back-end changes. We can do that later if that's really necessary

From my day of play, this wasn't a big deal. I agree that it's an optimization that we can deal with later.

>  2. Dropping anywhere else outside the browser window -> detach

I couldn't get this to work on OSX or Windows - on both platforms dragging outside the window would only detach when the drop location couldn't otherwise handle the drop (created shortcuts on the desktop, for example).

>  3. Dropping on the content area, by the height of a tab off the tabbar ->
> nothing

This ended up feeling "too sticky". The specification called for "more than 50%" and I think that will feel better than 100% of a tab's height. If you think it might still be too easy to accidentally detach at 50%, though (which is why I'm presuming you put it to 100% of the height) we can go for 66% instead.

Also, I found that the sensitivity changed after I tried a drag that *didn't* detach. If I did:

 - load the browser, open a new tab
 - drag that tab into the content area
 ---> it detached

 - load the browser, open a new tab
 - drag that tab onto an invalid drop location
 - drag that tab into the content area
 ---> it wouldn't detach unless I really went far into the content area

>  3. Dropping anywhere else within the content area ("down enough" and not on a
> text field) -> detach

Yup, this worked fine.

>  4. Dropping on chorme element which handled URLs in Firefox 3 -> same as in
> Firefox 3
>  5. Dropping on the tabbar -> same as in Firefox 3
>  6. Dropping anywhere else on the browser chrome -> nothing.

These all worked fine.

> I think we should land this and see how it feels.

This patch will definitely stop the accidental drops, and the design itself gets my ui-r, though I think that there are some bugs in in. We should get it in on trunk ASAP, IMO.

Connor: will you have an opportunity to review this today? Should we assign the review elsewhere?

Comment 23

[Mike Beltzner [:beltzner, not reading bugmail]]

Since we have the extra time before freeze, we should definitely get this in for Beta 3.

Comment 25

[Mike Connor [:mconnor]]

Comment on attachment 357493 [details] [diff] [review]
patch

this all looks good, trivial spelling fixes only.

>+        // If the tab was dragged from some other tabbaer, its own dragend
>+        // handler will take care of detaching teh tab

"tab bar" "the" ;)


>-            // If the tab was already selected (this happpens in the scenraio of
>-            // _replaceTabWithWindow), notify onLoactionChange, etc.
>+            // If the tab was already selected (this happpens in the scenraio

scenario

>+            // of replaceTabWithWindow), notify onLoactionChange, etc.

onLocationChange

Comment 26

[Mike Beltzner [:beltzner, not reading bugmail]]

Can we get an ETA on a landing with mconnor's comments addressed?

Comment 27

[Mike Beltzner [:beltzner, not reading bugmail]]

Can that ETA be "by Thursday"?

Comment 28

[Asaf Romano (gone)]

Yes.

Comment 29

[Robert Strong (they/them - no direct email)]

Attachment: patch w/ nits picked

carrying forward reviews

Comment 30

[Robert Strong (they/them - no direct email)]

Pushed to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/260df679b20d

Comment 31

[Robert Strong (they/them - no direct email)]

Pushed to mozilla-1.9.1
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/9677efd04315

Comment 32

[Asaf Romano (gone)]

I guess I should have attach the final patch.. the other fixes are coming (from beltzner's comments).

Comment 33

[Asaf Romano (gone)]

Attachment: fixes for beltzner's bugs

Comment 34

[Robert Strong (they/them - no direct email)]

Had a bad merge on the branch so I also pushed
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/2f4f2bf2e3e9

Note:
 var contentAreaDNDObserver = {
   onDrop: function (aEvent, aXferData, aDragSession)
     {
the following two lines are only on trunk and were added in bug 471438
       if (aEvent.getPreventDefault())
         return;

Comment 35

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Correcting TM to FF3.2a1. We have fixed1.9.1 to indicate it went into 1.9.1 branch.

Comment 36

[Robert Strong (they/them - no direct email)]

Henrik, actually we have TM to indicate the earliest target milestone where the patch landed.

Comment 37

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #36)
> Henrik, actually we have TM to indicate the earliest target milestone where the
> patch landed.

Please see the in-length discussion in mozilla.dev.planning about this topic.

Comment 38

[Henrik Skupin [:whimboo][⌚️UTC+1]]

The patch on this bug has resolved mostly every remaining issue for dependent bugs. Marking as verified.

Comment 39

[Michael Lefevre]

Hope I'm not just adding noise, but as far as I can see, mano's most recent patch addressing the stuff in Beltzner's comment 22 hasn't been landed. Is that still supposed to happen and if so should it be tracked somehow? Followup bug? Reopen this one?

Comment 40

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #39)
> Hope I'm not just adding noise, but as far as I can see, mano's most recent
> patch addressing the stuff in Beltzner's comment 22 hasn't been landed. Is that
> still supposed to happen and if so should it be tracked somehow? Followup bug?
> Reopen this one?

Robert, how should we handle this?

Comment 41

[Robert Strong (they/them - no direct email)]

IMO it would be preferable if the additional items were fixed in a separate bug. It also doesn't appear that the additional patch has actually been reviewed though it has been plussed by Mano. Can you try to contact Mano to get him to get the remaining patch reviewed and landed?

Comment 42

[Asaf Romano (gone)]

It doesn't need any further reviews. I'll land it today.

(

Comment 43

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to comment #42)
> It doesn't need any further reviews. I'll land it today.
> 
> (

Did I miss something, or has this still not landed ?

Comment 44

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #43)
> (In reply to comment #42)
> > It doesn't need any further reviews. I'll land it today.
> 
> Did I miss something, or has this still not landed ?

Tony, can you take care of this?

Comment 45

[Asaf Romano (gone)]

mozilla-central: c89aafbc7fdb / ad04b0283f8a
mozilla-1.9.1: a6dd64423d85

Comment 46

[Damian Shaw [Quan]]

As of:

Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b3pre) Gecko/20090213 Shiretoko/3.1b3pre ID:20090213033101

Dragging on to the desktop (Windows XP x64) creates a shortcut on the desktop. Is this the intended behavior?

Comment 47

[Henrik Skupin [:whimboo][⌚️UTC+1]]

See bug 475066 and bug 471955.

Comment 49

[Teoh Han Hui]

I believe there are still many problems associated with the tab tearing behaviour in Firefox 3.1 Beta 3. OS: Windows Vista SP2 RC

1. Dropping a tab in its own document window should not tear it off.
2. It should be possible to drop a tab into a minimized window on the taskbar (the target should be restored for tab dropping).
3. When dropping a tab onto the taskbar or desktop the 'unavailable' mouse pointer is shown which is clearly misleading.
4. It is unnecessary to recreate a new window when 'the single tab in its own window' is dropped into its own document window (while dropping it onto the taskbar or desktop does nothing).

Comment 50

[Michael Lefevre]

(In reply to comment #49)
> I believe there are still many problems associated with the tab tearing
> behaviour in Firefox 3.1 Beta 3. OS: Windows Vista SP2 RC

Maybe, but this bug is "fixed" according to its original description.
Each issue should be filed in its own bug (or discussed outside of bugzilla).

> 1. Dropping a tab in its own document window should not tear it off.

That is by design. If you have a window taking most or all of the screen, you can't drag it "off" to somewhere else.

> 2. It should be possible to drop a tab into a minimized window on the taskbar
> (the target should be restored for tab dropping).

I don't recall seeing a bug for that - if there isn't one, it should be filed.

> 3. When dropping a tab onto the taskbar or desktop the 'unavailable' mouse
> pointer is shown which is clearly misleading.

That sounds like bug 463088.

> 4. It is unnecessary to recreate a new window when 'the single tab in its own
> window' is dropped into its own document window (while dropping it onto the
> taskbar or desktop does nothing).

I am sure I have seen a bug about this but I can't find it. If a bug doesn't
exist already, someone should file it.

Comment 51

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #50)
> > 4. It is unnecessary to recreate a new window when 'the single tab in its own
> > window' is dropped into its own document window (while dropping it onto the
> > taskbar or desktop does nothing).
> 
> I am sure I have seen a bug about this but I can't find it. If a bug doesn't
> exist already, someone should file it.

Bug 474908 which doesn't went into 3.1b3.