475066 - dragging a tab out of the browser window doesn't detach the tab (i.e. opens a window for that tab)

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect, P1)

Description

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

Since the landing of the patch in bug 471499, tabs no longer detach from the tab strip when dragged outside of the browser window. If dragged to the desktop they create shortcuts.

Mano says he knows what's causing this and will fix.

Comment 1

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

Are you sure that creating a 'short-cut' is not the preferred behavior.  I suspect any number of people are today dragging either the tab and/or favicon to the desktop for just that, create a short-cut.  

Dragging the tab to desktop to create a tear-off, i.e. New window is going to be surprizing behavior I suspect.

Comment 2

[IU]

I very much prefer the current behavior.  Can we instead have an option to allow creating shortcuts when dragging to Windows Explorer?  Otherwise, how about an option to disable detaching altogether?

Comment 3

[IU]

By current behavior I meant that I want to be able to create a shortcut when dragging outside the browser window.

Comment 4

[Dave Garrett]

(In reply to comment #2)
> I very much prefer the current behavior.  Can we instead have an option to
> allow creating shortcuts when dragging to Windows Explorer?

If you can make it detect Explorer, Finder, Dolphin/Konqueror, Nautilus, etc. and do this reliably, that'd make sense. However this doesn't really sound like a natural behavior as most users would expect to be able to do drop URLs onto the desktop too.

Maybe just add some popup text to tell the user what it's going to do when they drop. When hovering over a window it'll tell them dropping makes a new window; when they're over the desktop or a file manager it'll tell them dropping makes a shortcut. Just having a cursor change doesn't seem to be enough here.

Comment 5

[IU]

@Dave Garrett:  I don't believe the problem is that complicated.  If you give your first-paragraph argument a 180 degree flip (no insult intended), the solution is much easier.  Specifically, if drag-dropping into those desktop environments is currently creating a shortcut, no need to mess with it.  You then would only need code for one scenario: if outside the browser window, detach.  Doing it that way, you don't care about desktop manager.

That way, it would be easier to support both cases, so that users who like the current behavior have a choice.

Comment 6

[Asaf Romano (gone)]

Please stop spamming this bug, this is neither a newsgroup (use m.d.a.fiirefox for that) nor a forum (use mozillazine).

Comment 7

[eyal gruss]

this has also affected Bug 470189 - dragging to an existing browser window (off tab strip) does nothing.

Comment 8

[Asaf Romano (gone)]

Attachment: This should work

Comment 9

[Mike Connor [:mconnor]]

Comment on attachment 361544 [details] [diff] [review]
This should work

>diff --git a/browser/components/places/content/controller.js b/browser/components/places/content/controller.js
>--- a/browser/components/places/content/controller.js
>+++ b/browser/components/places/content/controller.js
>+      // urls can be dropped on any insertionpoint
>+      // XXXmano: we shouldn't use unwrapNodes here at all if possible.

please explain why not, otherwise the comment may be rather opaque

Comment 10

[Asaf Romano (gone)]

Attachment: as checked in

Comment 11

[Asaf Romano (gone)]

mozilla-central: b4bf19fdef47
mozilla-1.9.1: d84f09471a8c

Comment 12

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

When I want to deteach a tab on Windows that way, I get a mouse pointer which shows me that the action is denied. But even when dropping the tab on the desktop I get a new window. Is there a bug which handles the mouse pointer problem?

Comment 13

[Luke Iliffe (Harlequin99)]

That would be bug 463088

Comment 14

[juan becerra [:juanb]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3) Gecko/20090304 Firefox/3.1b3
(20090304215011)

Dragging a tab out of the browser window is not working on Linux with fx3.1b3build1. The thumbnail appears as you drag the tab, and you try to release it onto the desktop it disappears, but no new window is spawned.

Using the context menu works, though.

Comment 15

[Asaf Romano (gone)]

Please open a new bug for the linux issue. It works afaict on both mac and windows.

Comment 16

[Tony Chung [:tchung]]

Verified fix on windows: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3) Gecko/20090304 Firefox/3.1b3
mac: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3) Gecko/20090304 Firefox/3.1b3
and mac trunk: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090305 Minefield/3.2a1pre

Comment 17

[juan becerra [:juanb]]

Tony, try dragging the tab out of the window.

Comment 18

[Tony Chung [:tchung]]

It seems like the more testing we're doing on this issue, the more inconsistent behavior we're seeing.   New research on this bug still happening has moved over to bug 481693.  We can either dupe that bug to this, or leave this bug verified and move investigation to the other bug.

Comment 19

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

Well, if this bug isn't FIXED it should be re-opened.

Comment 21

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

To be clear: re-opening as Juan is seeing this on more than just Linux, implying that it's not actually fixed in multiple OSes.

Comment 22

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

Moving over relnote from bug 481693.

Comment 23

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

--> P1, as this bug will require the wider feedback of a beta release or is of sufficient complexity that we should be looking at it sooner, not later.

Comment 24

[Michael Kraft [:morac]]

I think I found a potential reason why this bug is affecting some, but not others.  I'm running the following build:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3 (.NET CLR 3.5.30729)


Without Tab Mix Plus installed, dragging a tab to the desktop detaches the tab and opens it in a new window.
With Tab Mix Plus 0.3.7.3 installed, dragging a tab to the desktop creates a shortcut.
With Tab Mix Plus 0.3.7.4pre.090107, dragging a tab to the desktop does nothing.

So make sure you are testing without any extensions installed.

Comment 25

[Tony Chung [:tchung]]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090312 Shiretoko/3.1b4pre

I actually have been using new profiles with no extensions at all.  My further observations is showing:

detaches the tab (desktop shortcut) and opens it in a new window:
- drag a tab to the SouthWest corner of the tabbar and out of the browser
- drag a tab to the NorthWest corner of the tabbar and out of the browser
- drag a tab to the directly North of the tabbar and out of the browser

detaches the tab (desktop shortcut) only, no new window:
- drag a tab directly West of the tabbar and out of the browser
- drag a tab any other direction that's not N, NW or SW.  (so NE, E, SE, S, and W)

Hope that helps.

Comment 26

[Asaf Romano (gone)]

Er, detach means "new window".

Comment 27

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

Asaf, ETA or thoughts?

Comment 28

[Asaf Romano (gone)]

Attachment: another attempt

Comment 29

[Neil Deakin]

Comment on attachment 368292 [details] [diff] [review]
another attempt

Seems OK, but I'd just call it text/x-moz-text-internal or something since it doesn't necessarily need to be editor related.

Comment 30

[Asaf Romano (gone)]

Comment on attachment 368292 [details] [diff] [review]
another attempt

ok

Comment 31

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 368292 [details] [diff] [review]
another attempt

Not quite sure why "editor" is in the flavor name. But sr=me either way.

Comment 32

[Asaf Romano (gone)]

With that change:
mozilla-central: 81d198ae47a5
mozilla-191: 3c4e7b8a6562

Comment 33

[(not currently active) Ted Mielczarek]

I backed this out of 1.9.1 to try to fix unittest orange. Sorry. :-(
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/e536dd81d066

Comment 34

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

Ted: which orange?

Comment 35

[(not currently active) Ted Mielczarek]

There were two cycles of orange with a hang on Windows unittests with this changeset + the following changesets:
http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox3.5&maxdate=1238146981&legend=0&norules=1
but of course after I backed them out it cycled green. :-/

Not sure what to think, there.

Comment 36

[jag (Peter Annema)]

It doesn't look like it was actually backed out. At least, none of the changes show up in the link from comment 33.

Three nits on the original check-in: "deatch" and "suppoed", and in nsITransferable.idl the string isn't indented properly.

Comment 37

[Asaf Romano (gone)]

Jag, it was backed out from the branch. Thanks for spotting the nits, I'll fix that as soon as I can.

Comment 38

[Kevin Brosnan]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090328 Minefield/3.6a1pre

Dragging a tab out of the browser Window causes it to go back to the current tab bar. The only way to detach a tab is to drop the tab in the active tab's content area.

Comment 39

[Kevin Brosnan]

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090328 Minefield/3.6a1pre

Dragging a tab over a current tab and releasing outside the browser causes the detach to cancel. To reproduce open 3 tabs drag the middle tab along the tab bar to the left or right. If you do this correctly you should see the arrow that shows the tab swap locations. It will not detach if you release it outside the browser.

Comment 40

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

Was this backed out of only branch, or also mozilla-central?

Comment 41

[(not currently active) Ted Mielczarek]

I only backed out on 1.9.1.

Comment 42

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

We should back it out of mozilla-central if it's caused an intermittent test fail on mozilla-1.9.1, as it might be intermittently failing on mozilla-central as well just on a different schedule. Especially considering according to comment 38 and comment 39, the patch doesn't do what it's meant to do.

Mano: can we get this backed out of m-c?

Comment 43

[(not currently active) Ted Mielczarek]

I don't know that it caused an intermittent failure there, it cycled orange twice with this + another checkin, and then cycled green. I backed it out on suspicion, since those were windows cycles, so it had been orange for ages.

Comment 44

[Asaf Romano (gone)]

beltzner: the landed patch is a must-have at least for the problem reported in comment 25. Indeed, we need few more frontend frontend changes.
I'm almost certain this patch didn't cause the orange on 191, simply because it lives in code that cannot be tested.

Comment 45

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

So should we get trunk and branch back in sync, then? From what I can tell, though, we're still talking about needing a new patch since this doesn't actually fix the problem, is that right?

Comment 46

[Asaf Romano (gone)]

Yes, we should.

As I said above, it fixes the mac part of at the very least (the problem reported on comment 25). I had a reason not to merge all these bugs into these one at first.

Comment 47

[Dietrich Ayala (:dietrich)]

(In reply to comment #46)
> Yes, we should.
> 
> As I said above, it fixes the mac part of at the very least (the problem
> reported on comment 25). I had a reason not to merge all these bugs into these
> one at first.

trying to clarify what needs to be done here - this sound right?

1. re-land on branch, keeping an eye on a possible orange
2. file new bugs for the problems not covered by this patch
3. would also be nice to fix those nits in comment #36

Comment 48

[Kevin Brosnan]

Filed bug 487260 for the Linux problems with tab detachment.
Filed bug 487263 for the Windows failure to detach when dragged over the tab bar.

Comment 51

[Asaf Romano (gone)]

Whiteboard updated.

Comment 52

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

Mano: you've got an ETA, is that for parts (1) and (2)? Who do we need to ensure is on deck for reviews here?

Comment 53

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

Neil: I haven't heard from Mano; are you up to speed on what needs to be done here / have thoughts or ideas on how to do this?

Comment 54

[Asaf Romano (gone)]

Seeing the progress in the other bug, I'll attach the very small change needed on the frontend side once the backend part is done (It helps a lot that it's fixed on all three platforms).

Comment 55

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

(In reply to comment #54)
> Seeing the progress in the other bug, I'll attach the very small change needed

Which other bug? Bug 471955?

> on the frontend side once the backend part is done (It helps a lot that it's
> fixed on all three platforms).

Is there an ETA on that? The whiteboard says 4/14, which was yesterday. Can you describe what you have left to do (and what needs to be done in the other bug?)

Comment 56

[Asaf Romano (gone)]

Attachment: frontend

Comment 57

[Asaf Romano (gone)]

Comment on attachment 368292 [details] [diff] [review]
another attempt

landed on branch again.

Comment 58

[Asaf Romano (gone)]

(In reply to comment #55)
> (In reply to comment #54)
> > Seeing the progress in the other bug, I'll attach the very small change needed
> 
> Which other bug? Bug 471955?
> 

No, bug 471955.

Comment 59

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

(In reply to comment #58)
> No, bug 471955.

I believe you meant bug 466379.

(In reply to comment #57)
> (From update of attachment 368292 [details] [diff] [review])
> landed on branch again.

Asaf, it would be really helpful when you would post the changeset too in the future. This went in as http://hg.mozilla.org/releases/mozilla-1.9.1/rev/bd7327546c9b

Comment 60

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

Did this land on mozilla-central?

Comment 61

[Asaf Romano (gone)]

No, it's not yet reviewed

Comment 62

[Neil Deakin]

Comment on attachment 372828 [details] [diff] [review]
frontend

>+            // Deatch happens only if the tab was drooped below the tabbar.

'drooped' -> 'dropped'

>+            var bo = this.mTabContainer.mTabstrip.boxObject;
>+            var tabbarEndScreenY = bo.screenY + bo.height;
>+            if (aEvent.screenY > tabbarEndScreenY) {
>               var draggedTab = dt.mozGetDataAt(TAB_DROP_TYPE, 0);
>               this.replaceTabWithWindow(draggedTab);

I expected an addition to open the window at the dropped screen coordinates. This should be pretty easy, by setting the left/top arguments to window.open. But a followup bug would be ok.

Comment 63

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

I'm not sure if Mano's still around: is there someone who can fix Enn's nit and get this checked in to mozilla-central?

Comment 64

[Asaf Romano (gone)]

Doing so now.

Comment 65

[Asaf Romano (gone)]

http://hg.mozilla.org/mozilla-central/rev/011726ff11de

Comment 66

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

Doesn't this depend on bug 466379 which has yet to land on mozilla-central? Do we expect your checkin to have done anything without that?

Comment 67

[Asaf Romano (gone)]

It has landed with no comment on the bug AFAICT.

Comment 68

[Asaf Romano (gone)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/0afd13e5e7eb

Comment 69

[tabmix.onemen]

after this was landed when draging tab to content area
aEvent.screenY in _onDragEnd is always 0

so we can not detach a tab by draging it to content area

Comment 70

[Asaf Romano (gone)]

On which OS? The linux part of bug 466379 might not be on the branch yet.

Comment 71

[tabmix.onemen]

win xp(In reply to comment #70)
> On which OS? The linux part of bug 466379 might not be on the branch yet.
win xp

Comment 72

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #69)
> after this was landed when draging tab to content area
> aEvent.screenY in _onDragEnd is always 0
> 
> so we can not detach a tab by draging it to content area

This has stopped indeed. (Tested on Windows XP/Vista.)

Comment 73

[Dão Gottwald [:dao]]

Please file a new bug.

Comment 74

[Alice0775 White]

The behaviour is mentioned in attachment of Comment #56
+ // Deatch happens only if the tab was drooped below the tabbar.
+ // That is applied even if it was dropped outside the browser
+ // window.

Anyway, It is strange behavior.

I think that drop a tab outside of browser should be detach it.

-            // Deatch happens only if the tab was dropped below the tabbar.
-            // That is applied even if it was dropped outside the browser
-            // window.
+            // Deatch happens only if the tab was dropped below the tabbar
+            // and outside of the browser window.
            var bo = this.mTabContainer.mTabstrip.boxObject;
            var tabbarEndScreenY = bo.screenY + bo.height;

-            if (aEvent.screenY > tabbarEndScreenY) {
+            if (aEvent.screenY > tabbarEndScreenY ||
+               aEvent.screenX < window.screenX  ||
+               window.screenX + window.outerWidth < aEvent.screenX) {
              var draggedTab = dt.mozGetDataAt(TAB_DROP_TYPE, 0);
              this.replaceTabWithWindow(draggedTab);
            }

Comment 75

[Alice0775 White]

In adittion to the above,
Comment #69 should be fixed.otherwise, it does not operate correctly.

Comment 76

[Alice0775 White]

Forgot whwn drop a tab above title bar.

-            // Deatch happens only if the tab was dropped below the tabbar.
-            // That is applied even if it was dropped outside the browser
-            // window.
+            // Deatch happens only if the tab was dropped below the tabbar
+            // and outside of the browser window.
            var bo = this.mTabContainer.mTabstrip.boxObject;
            var tabbarEndScreenY = bo.screenY + bo.height;

-            if (aEvent.screenY > tabbarEndScreenY) {
+            if (aEvent.screenY > tabbarEndScreenY ||
+               aEvent.screenY < window.screenY ||
+               aEvent.screenX < window.screenX  ||
+               window.screenX + window.outerWidth < aEvent.screenX) {
              var draggedTab = dt.mozGetDataAt(TAB_DROP_TYPE, 0);
              this.replaceTabWithWindow(draggedTab);
            }

Comment 77

[Ria Klaassen (not reading all bugmail)]

Sorry, I don't understand Alice's comments, is not detaching a tab by dragging it into the content area intentional?

FYI, the tab detaching by dragging to desktop does not work anymore if you're using this userChrome.css: 

/* Show tabs at bottom */
#content > tabbox { -moz-box-direction: reverse; }

Comment 78

[Alice0775 White]

(In reply to comment #77)
> Sorry, I don't understand Alice's comments, is not detaching a tab by dragging
> it into the content area intentional?
> 
> FYI, the tab detaching by dragging to desktop does not work anymore if you're
> using this userChrome.css: 
> 
> /* Show tabs at bottom */
> #content > tabbox { -moz-box-direction: reverse; }
NO.
The patch of Comment #56, A tab is detached only when a tab is dropped below the line which lengthened the bottom of a tab bar(of course  inclding content area).

But Comment #76, the tab can detach when a tab is dropped  not only below a tab bar, and also the desktop whole region of the outside of a browser.

Comment 79

[Nochum Sossonko [:Natch]]

Pascal filed this latest find as bug 489114.

Comment 81

[Aakash Desai [:aakashd]]

A tab dragged and dropped outside the browser, onto the desktop, does not detach it into a new window in the Fx 3.5b4 rc.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 ID:20090423191946

Comment 82

[Gabriela [:gaby2300]]

Dragging a tab outside the browser detaches into a new window only if it's dragged in any direction bellow the tab bar. If dragged up North, it doesn't.

Mozilla/5.0 (Windows; U; Windows NT 5.1; es-AR; rv:1.9.1pre) Gecko/20090522 Shiretoko/3.5pre

Comment 83

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

(In reply to comment #82)
> Dragging a tab outside the browser detaches into a new window only if it's
> dragged in any direction bellow the tab bar. If dragged up North, it doesn't.

That works fine for me with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090525 Shiretoko/3.5pre (.NET CLR 3.5.30729) ID:20090525041408. If you can reproduce it with a clean profile and good STR please file a new bug and mention it here.

Please also be aware of bug 494795 which handles the last remaining issues on Linux and OS X.

Marking verified fixed by my observations on all platforms.

Comment 84

[Gabriela [:gaby2300]]

Actually whenever I drag a tab downwards a window detaches but I cannot close that window nor the original one. Should I resize the first window so as to have some space between the window and the desktop, if I drag a tab upwards towards the desktop window detaches but I cannot close that window nor the original one.
This is only solved opening a new profile but I'm really tired of doing this because I have to reinstall all my extensions, paswords, usersnames, ect. It's really vexing!
I really hope you'll solve this issue because I find FF RC2 great except this issue.

Comment 85

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

Gabriela, please file a new bug when you think this is an issue which has to be fixed. Personally I cannot reproduce the described behavior with a recent build on WinXP. So please give clear STR in the newly filed bug and eventually a screencast. That would help a lot. Thanks!

Comment 86

[Gabriela [:gaby2300]]

(In reply to comment #85)
> Gabriela, please file a new bug when you think this is an issue which has to be
> fixed. Personally I cannot reproduce the described behavior with a recent build
> on WinXP. So please give clear STR in the newly filed bug and eventually a
> screencast. That would help a lot. Thanks!

Henrik, today the issue seems to be solved except I cannot exit Firefox by clicking the red cross at the upper right corner as I usually did, only by File>Exit. Should the issue with the windows appear again, could you please tell me what do you mean by clear STR? Many thanks, Gabriela