465910 - Drag&Drop of tab onto home button opens the tab in a new window

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect, P2)

Description

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

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081119 Minefield/3.1b2pre ID:20081119053142

This bug is a regression from Firefox 3.0 and should happen because of the check-in of the patch on bug 113934. If you drag&drop any of your open tabs onto the home button, a new window gets opened. Instead you should see the question to set it as your home page.

Steps to reproduce:
1. Open at least two tabs so you will see the tab bar.
2. Drag the tab onto the home button
3. Repeat step 2

With step 2 a new window gets opened. You get repeat it with step 3. Each action will open this tab in a new window.

Comment 1

[Sylvain Pasche]

Maybe it is rather a regression from bug 225680

Comment 2

[Boris Zbarsky [:bzbarsky]]

Yeah.  This has nothing to do with bug 113934.

Comment 3

[Marcia Knous [:marcia]]

Henrik: I don't see this bug using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081120 Minefield/3.1b2pre and on my nightly running on Tiger. When I drag a tag to the home icon it gives me the home page prompt.

Comment 4

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

Thanks Sylvain for correcting my false assumption. I should have better searched.

Marcia, I can reproduce this bug on Windows and OS X on different computers. No idea why you cannot see it. I can reliable reproduce it.

Following error is shown in the Error Console when doing step 2 from comment 0:

Error: transferData.first is null
Source File: chrome://global/content/nsDragAndDrop.js
Line: 458

With step 3 I even get a less meaningful exception by a mouse down on a tab:

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsISupports.QueryInterface]"  nsresult: "0x80004002 (NS_NOINTERFACE)"  location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0"  data: no]

Comment 5

[Marcia Knous [:marcia]]

The QueryInterface exception is not related and is being fixed in a different bug. I will continue to try to see if I can reproduce but right now I cannot. Are there any extensions installed in your profile?

Comment 6

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

No, in both cases its a fresh profile without any add-on installed.

Comment 7

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

So this bug is similar to bug 465332. How should it be handled - separately?

Comment 8

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

No, I think probably together. We should be figuring out what valid drop ranges are for tear-off tabs. No need to differ from Safari and Chrome here; I think they get it right. When we drag outside "chrome" (toolbars, window border) we should tear of the tab. Otherwise we should be looking for the activities from other drop targets.

Comment 9

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

Verified on trunk and 1.9.1 with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090125
Shiretoko/3.1b3pre (.NET CLR 3.5.30729) ID:20090125052901

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre)
Gecko/20090126 Shiretoko/3.1b3pre Ubiquity/0.1.5 ID:20090126020313

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090125
Minefield/3.2a1pre ID:20090125034316

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre)
Gecko/20090126 Minefield/3.2a1pre ID:20090126020316

Comment 10

[Dão Gottwald [:dao]]

Has this regressed again? See bug 491530 for details.

Comment 11

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

It's a new regression so it should be handled on its own. Isn't it possible to have an automated test for this regression?

Comment 12

[Dão Gottwald [:dao]]

(In reply to comment #11)
> It's a new regression

Doesn't matter. There's no work that happened actually in this bug, and it's already blocking.

Comment 13

[u279076]

Litmus testcase added:
https://litmus.mozilla.org/show_test.cgi?id=12791