469176 - Attempting to drag a tab onto another application creates a new window instead

Status: RESOLVED WONTFIX

(Firefox :: Tabbed Browser, defect)

Description

[Jennifer]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2

Many applications in OS X are designed to allow you to drag and drop things in various ways, including dragging and dropping URLs from browsers (or other applications) into places where either an HTML link, the text URL itself, or a link with the title of the page as the text would be useful. For example, if a user wishes to share a page being read (or a Twitter tweet, which I use as a reference in my demonstration movie) with someone via instant message.

Reproducible: Always

Steps to Reproduce:
1. Click and hold title in tab
2. Drag from Firefox window onto input area of other app
3. Firefox creates a new window containing the tab


Expected Results:  
Expected to see:

1. Click and hold title in tab
2. Drag from Firefox window onto input area of other app
3. A link (either the title of the tab [ideally], or the text URL itself [as was the case in the Twitterific reference movie], should appear in the input area of the target app

Comment 1

[Jennifer]

Attachment: QuickTime movie showing how Twitterific handles this

This is close to ideal (the title is missing, but tweets don't have titles). Detects that it's being dragged into a text input area, creates a link to the resource being dragged

Comment 2

[Jennifer]

Attachment: QuickTime movie showing new window creation instead of desired result

This movie shows an attempt to drag and drop a tab onto an outgoing IM. A second window is created instead -- Firefox removes the tab from the tab bar, puts it into a new window, and totally ignores the target application (note that nothing appears into the text input area). Target app is Adium 1.3.2 in both movies.

Comment 3

[Steven Michaud [:smichaud] (Retired)]

Same thing happens on Windows (with a recent Minefield nightly), so ->
All.

I tried dragging a tab from Firefox 3.0.4 to Safari (on OS X) and to
IE (on Windows) -- which worked fine.  But Minefield seems to
interpret the same action as tearing off a tab from one window to
create another.

Furthermore, you only actually get the results described in comment #0
if your Minefield window has more than one tab open (the tab gets
removed from the first window and loaded into the second, new window).
If the "first" window has only one tab, nothing happens at all.

Comment 4

[Jesse Ruderman]

There are a few cases (bug 468553, bug 465910, bug 465332) where one could argue that it's worth making an exception to "drag tab anywhere to detach".  I think this one is especially hard to argue for, since the targets in question are far away from the tab bar and depend on what other windows you have open.

You can always drag the proxy icon (favicon) instead of the tab when you want your action to unambiguously indicate that you are dragging a URL/location.

Comment 5

[Sjoerd]

If I drag a tab a few pixels, an icon shows it is not droppable but when I do drop it, a new window is created. I expect nothing to happen. First because the icon shows it is not droppable, second because I drag the tab to its original location.

It is easy to trigger this bug by accident, because I sometimes accidentally drag a tab when clicking on it to select it.

Comment 6

[Jesse Ruderman]

Sjoerd, that's not this bug.  If you don't see your bug in the dependency list of bug 225680, please file a new one.

Comment 7

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

(In reply to comment #6)
> Sjoerd, that's not this bug.  If you don't see your bug in the dependency list
> of bug 225680, please file a new one.

That's bug 465346.

Comment 8

[Nochum Sossonko [:Natch]]

And the cursor thing is bug 463088

Comment 10

[Nochum Sossonko [:Natch]]

So I believe this has been fixed now (both on trunk and 1.9.1/5), marking correct me if I'm wrong.

Comment 11

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

Why you assume that? You should check it first before marking this bug as resolved. It's not fixed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090311 Minefield/3.2a1pre (.NET CLR 3.5.30729) ID:20090311051703

Comment 12

[Nochum Sossonko [:Natch]]

I did check (dragged a tab from 3.1 to 3.0, which works now), can you explain what you mean by not fixed?

Comment 13

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

Take Komodo as example. Using d&d and placing the tab into the editor area adds the URL to the content but also tears-off the tab into a new window. This happens with trunk and 1.9.1 on OS X.

Comment 14

[juan becerra [:juanb]]

Added Litmus test case https://litmus.mozilla.org/show_test.cgi?id=7605

Comment 15

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

While testing Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 those steps always results in a detached window while trying to drop into different text editors.

Comment 16

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

This doesn't block final release.

The drop should figure out what the best option is, and do that. If the drop target accepts rich text, we should paste the page title in as an HTML link to the URL; if the drop target only accepts text, we should just drop in the URL; if the drop target doesn't accept anything, we should create a new window.

For now, the workaround is to drag the URL from the locationBar instead of the tab itself.

I am pretty sure this is a dupe.

Comment 17

[Jesse Ruderman]

I think this should be WONTFIX, since no app can accept an entire "Firefox tab".  Making a dragged tab act like a dragged URL depending on where it's dropped would cause a lot of unexpected behavior.

Comment 18

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

Jesse: not sure why we shouldn't try to do the smart thing; many elements of desktop UIs will behave differently depending on the drop target, no reason why we can't be smart as well.

Comment 19

[Jesse Ruderman]

Because it would decrease the usability of the detach-tab feature without really making other things easier.  At best, you'd have to look for "empty" space instead of just tossing the tab out of the window; at worst, the result of dragging a tab out would feel "random".

Comment 20

[Tony Chung [:tchung]]

Adding [FFT3.5] in whiteboard.  Came across this issue during RC1 testing

Comment 21

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

Reading the latest comments we have a discrepancy what we really wanna have. Adding the uiwanted keyword so we get feedback from the UX team.

Meanwhile I have tested it with Safari on OS X and it also creates a new window and doesn't insert the URL into the editors content.

Comment 22

[Tom Edwards]

This problem would be neatly resolved if dragging a favicon behaved in the manner described by Mike in comment #16. As it stands only the raw URL is delivered by favicon drags, even to rich text controls.

Whether users familiar with dragging tabs would know to drag a favicon instead is debatable, but it's certainly the first thing I tried when I realised what dragging the tab had done.

Comment 23

[Jacob Harvey]

(In reply to comment #22)
> This problem would be neatly resolved if dragging a favicon behaved in the
> manner described by Mike in comment #16. As it stands only the raw URL is
> delivered by favicon drags, even to rich text controls.
> 
> Whether users familiar with dragging tabs would know to drag a favicon instead
> is debatable, but it's certainly the first thing I tried when I realised what
> dragging the tab had done.

I'd have to agree. In previous versions I used tab dragging to insert links in an email, which included the title. Now it's difficult to decipher things with just the URL.

Comment 24

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

I'm not sure people really expect the tab to resolve to a URL when you drag it, since this isn't a direct manipulation (the tab is well, the tab).  Supporting URL dragging by allowing users to drag the URL to whatever text field they like is a more discoverable and conceptually pure behavior.

Comment 25

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

(In reply to comment #24)
> I'm not sure people really expect the tab to resolve to a URL when you drag it,
> since this isn't a direct manipulation (the tab is well, the tab).  Supporting
> URL dragging by allowing users to drag the URL to whatever text field they like
> is a more discoverable and conceptually pure behavior.

Given the feedback from Alex does it mean we don't want to fix this particular item? Mike? I would like to update our Litmus test because we get a lot of failed tests in the last weeks and it always takes time for me to vet those. Having a decision on this action would be great. Thanks.

Comment 26

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

The following both litmus tests have been disabled for now until we have a decision on the expected behavior:

https://litmus.mozilla.org/show_test.cgi?id=7605
https://litmus.mozilla.org/show_test.cgi?id=9260

Comment 27

[Tom Edwards]

I'd still like to see Comment #22 implemented.

Comment 28

[Yuan Wang(:Yuan) – Mobile Firefox Design Lead]

I agree with the Comment #24. Supporting dragging favicon instead of tab makes better sense. The intent of dragging favicon is clear enough for users to expect the result. Currently FX 10 supports dragging favicon already. So this bug should be clear.

Comment 29

[:Gavin Sharp [email: [e-mail]]]

Sounds like you meant to use WONTFIX? FIXED should generally only be used when we actually land a patch.

Comment 30

[Dão Gottwald [:dao]]

(In reply to Yuan Wang(:Yuan) – Firefox UX Team from comment #28)
> I agree with the Comment #24. Supporting dragging favicon instead of tab
> makes better sense. The intent of dragging favicon is clear enough for users
> to expect the result. Currently FX 10 supports dragging favicon already. So
> this bug should be clear.

It's going away in bug 588270.