560791 - The "tab tear" feature no longer works when dropping on content

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[andyterminator_367]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100420 Minefield/3.7a5pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100420 Minefield/3.7a5pre (.NET CLR 3.5.30729)

In the latest Minefield 3.7 nightly update I've noticed that - along with a new look for tabs - the "tab tear" feature no longer works. My understanding is that this is the name of the feature wherein when a tab is pulled down from its location and into the page, it pops out and opens in a new window. In the latest nightly update however it doesn't do that. Rather, it simply refreshes the page. Is this a bug, or is it intended? Either way I'm not impressed.

Reproducible: Always

Steps to Reproduce:
1. Open a new web page in a tab
2. Pull it out like you would in Firefox 3.6
3. Expect it to open in a new Window; be disappointed.
Actual Results:  
1. Opened a new web page in a tab
2. Pulled it out like I did in Firefox 3.6
3. The page refreshed. I wanted it to open in a new window

Expected Results:  
1. Open a new web page in a tab
2. Pull it out like you would in Firefox 3.6
3. Tab is removed from previous window; tab now has its own window

Comment 1

[John P Baker]

There have also been some changes to drag and drop recently.

Comment 2

[John P Baker]

I think this is probably a regression from bug 556739. I'm not sure that TAB_DROP_TYPE is defined in tabbrowser.js scope any more; In particular compare with bug 556739 comment #36 onwards.

Comment 3

[Marco Bonardo [:mak]]

(In reply to comment #2)
> I think this is probably a regression from bug 556739. I'm not sure that
> TAB_DROP_TYPE is defined in tabbrowser.js scope any more; In particular compare
> with bug 556739 comment #36 onwards.

that's only about tab drop on Places views, should not hit any other kind of drop.

Comment 4

[Marco Bonardo [:mak]]

(In reply to comment #3)
> that's only about tab drop on Places views, should not hit any other kind of
> drop.

Unless somebody was using a const defined by us, that would be absolutely wrong, but possible!

Comment 5

[Marco Bonardo [:mak]]

hm, no it is defined in utilityOverlay
line 44 -- var TAB_DROP_TYPE = "application/x-moz-tabbrowser-tab";
http://mxr.mozilla.org/mozilla-central/source/browser/base/content/utilityOverlay.js#44

so only Places views could have been affected, and those are fine in current nightly

Comment 6

[Marco Bonardo [:mak]]

i must also add that it works perfectly here following steps in comment 0
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100420 Minefield/3.7a5pre

Comment 7

[John P Baker]

Sorry, I have confirmed that mak is right and TAB_DROP_TYPE _is_ defined - before I couldn't find where utilityOverlay was included.

When I drag a tab to content area the page reloads instead of detaching.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.3a5pre) Gecko/20100420 Minefield/3.7a5pre ID:20100420040941

Comment 8

[Marco Bonardo [:mak]]

oh, to content area, i can confirm that... i think this is an ever better behavior than the previous, but this is a personal opinion.
Most likely due to Neil's droplinkhandler changes, he touched browser drop link code.

Comment 9

[andyterminator_367]

I believe that any tab which has some flash content loaded will successfully open in a new window when dragged to the content area. If that flash content has not loaded (i.e. the Flashblock plugin is preventing it) the page will not detach successfully; only when the flash content is allowed to load can the tab detatch.

Comment 10

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

I can also confirm this bad change on XP
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100421 Minefield/3.7a5pre

and this isn't better behavior, if I want to refresh page I will click F5 or simply reload button ;)

Comment 11

[Neil Deakin]

Attachment: fix

Comment 12

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Can this patch can finally land to restore this future like it was before in previous nightlys ? ;)

Comment 13

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to comment #12)
> Can this patch can finally land to restore this future like it was before in
> previous nightlys ? ;)

The patch is waiting on review and will land after it gets r+ from mano.

Comment 14

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

I know, that's why I writing my message to speed up reviewing this small patch to restore main Fx future.

Comment 15

[Asaf Romano (gone)]

Comment on attachment 440568 [details] [diff] [review]
fix

r=mano

Comment 16

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

So can patch land finally ? ;)

Comment 17

[Neil Deakin]

http://hg.mozilla.org/mozilla-central/rev/27e8026d2cc7

Comment 18

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

Thanks Neil! That fixes the problem on all platforms with builds like Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a5pre) Gecko/20100514 Minefield/3.7a5pre ID:20100514030623

Comment 19

[Dietrich Ayala (:dietrich)]

posthumous blocking+.