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

VERIFIED FIXED in Firefox 3.6a1

Status

()

Firefox
Tabbed Browser
P1
normal
VERIFIED FIXED
9 years ago
7 years ago

People

(Reporter: beltzner, Assigned: mano)

Tracking

(Blocks: 1 bug, {verified1.9.1})

Trunk
Firefox 3.6a1
verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3.5 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

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.
Flags: blocking-firefox3.1+
Priority: -- → P2
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

9 years ago
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

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

Comment 4

9 years ago
(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.
Hardware: x86 → All

Comment 5

9 years ago
@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.
Please stop spamming this bug, this is neither a newsgroup (use m.d.a.fiirefox for that) nor a forum (use mozillazine).

Comment 7

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

Updated

9 years ago
Blocks: 471955
Created attachment 361544 [details] [diff] [review]
This should work
Attachment #361544 - Flags: review?(mconnor)
Whiteboard: [needs review 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
Attachment #361544 - Flags: review?(mconnor) → review+

Updated

9 years ago
Whiteboard: [needs review mconnor] → [has reviews]
Whiteboard: [has reviews] → [needs landing]
Whiteboard: [needs landing] → [has reviews, needs update & landing]
Created attachment 363088 [details] [diff] [review]
as checked in
Attachment #361544 - Attachment is obsolete: true
mozilla-central: b4bf19fdef47
mozilla-1.9.1: d84f09471a8c
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Keywords: fixed1.9.1
Resolution: --- → FIXED
Whiteboard: [has reviews, needs update & landing]
Target Milestone: Firefox 3.1 → Firefox 3.2a1

Updated

9 years ago
No longer blocks: 471955
Depends on: 471955
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?
That would be bug 463088
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Please open a new bug for the linux issue. It works afaict on both mac and windows.
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED

Updated

9 years ago
Blocks: 481693
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
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
Tony, try dragging the tab out of the window.
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.
Well, if this bug isn't FIXED it should be re-opened.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Duplicate of this bug: 481693

Updated

9 years ago
Keywords: verified1.9.1
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.
Moving over relnote from bug 481693.
Keywords: relnote
Status: REOPENED → ASSIGNED
--> 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.
Priority: P2 → P1
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.
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.
Er, detach means "new window".
Summary: dragging a tab out of the browser window doesn't detach the tab → dragging a tab out of the browser window doesn't detach the tab (i.e. opens a window for that tab)
Asaf, ETA or thoughts?
Whiteboard: [needs ETA]
Created attachment 368292 [details] [diff] [review]
another attempt
Attachment #368292 - Flags: review?
Whiteboard: [needs ETA] → [needs review enn]
Attachment #368292 - Flags: review? → review?(enndeakin)
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.
Attachment #368292 - Flags: review?(enndeakin) → review+
Comment on attachment 368292 [details] [diff] [review]
another attempt

ok
Attachment #368292 - Flags: superreview?(jonas)
Whiteboard: [needs review enn] → [needs review jonas]
Comment on attachment 368292 [details] [diff] [review]
another attempt

Not quite sure why "editor" is in the flavor name. But sr=me either way.
Attachment #368292 - Flags: superreview?(jonas) → superreview+
Whiteboard: [needs review jonas] → [needs landing]
With that change:
mozilla-central: 81d198ae47a5
mozilla-191: 3c4e7b8a6562
Whiteboard: [needs landing] → needs testing on all platfroms
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

Updated

9 years ago
Whiteboard: needs testing on all platfroms → [needs landing] needs testing on all platfroms
Ted: which orange?
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

9 years ago
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.
Jag, it was backed out from the branch. Thanks for spotting the nits, I'll fix that as soon as I can.

Comment 38

9 years ago
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

9 years ago
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.
Was this backed out of only branch, or also mozilla-central?
Whiteboard: [needs landing] needs testing on all platfroms → needs testing on all platfroms
I only backed out on 1.9.1.
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?
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.
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.
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?
Whiteboard: needs testing on all platfroms → [needs new patch]
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.
(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

9 years ago
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.
Duplicate of this bug: 487260
Duplicate of this bug: 487263
Whiteboard updated.
Whiteboard: [needs new patch] → [ETA: 4/14] 1) land backend patch on branch 2) patch frontend
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?
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?
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).
(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?)
Whiteboard: [ETA: 4/14] 1) land backend patch on branch 2) patch frontend → [needs review enn][backend part landed on branch][depends on bug 466379 landed on bracnh too]
Created attachment 372828 [details] [diff] [review]
frontend
Attachment #372828 - Flags: review?(enndeakin)
Comment on attachment 368292 [details] [diff] [review]
another attempt

landed on branch again.
(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.
Depends on: 466379
No longer depends on: 471955
(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
Did this land on mozilla-central?
No, it's not yet reviewed
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.
Attachment #372828 - Flags: review?(enndeakin) → review+
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?
Whiteboard: [needs review enn][backend part landed on branch][depends on bug 466379 landed on bracnh too] → [needs landing][needs bug 466379 landed on 1.9.1]
Doing so now.
http://hg.mozilla.org/mozilla-central/rev/011726ff11de
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing][needs bug 466379 landed on 1.9.1] → [needs bug 466379 landed on 1.9.1]
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?
It has landed with no comment on the bug AFAICT.
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/0afd13e5e7eb
Keywords: relnote → fixed1.9.1
Whiteboard: [needs bug 466379 landed on 1.9.1]

Comment 69

9 years ago
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
On which OS? The linux part of bug 466379 might not be on the branch yet.

Comment 71

9 years ago
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
(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.)
Please file a new bug.

Updated

9 years ago
Depends on: 488978

Updated

9 years ago
Depends on: 488981

Comment 74

9 years ago
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

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

Comment 76

9 years ago
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);
            }
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

9 years ago
(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.
Depends on: 489114
Pascal filed this latest find as bug 489114.
Depends on: 489339
No longer depends on: 489114

Updated

8 years ago
Duplicate of this bug: 487260
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
Depends on: 491530
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
(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.
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
Depends on: 498367
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.
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!
(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

Updated

8 years ago
Blocks: 467530
You need to log in before you can comment on or make changes to this bug.