474908 - Dragging a tab in a window with only one tab detaches the tab

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect, P2)

Description

[Nochum Sossonko [:Natch]]

With the patch from bug 471499, dragging a tab into the content area closes firefox then reopens with a new tab. The problem is, I think, that contentAreaDNDObserver doesn't check if there's only one tab before detaching.

Comment 1

[Nochum Sossonko [:Natch]]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090123 Minefield/3.2a1pre

Confirmed on the nightly.

Comment 2

[Dão Gottwald [:dao]]

That check should probably happen in tabbrowser's replaceTabWithWindow.

Comment 3

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

Also happens on OS X.

Comment 4

[Dão Gottwald [:dao]]

Attachment: patch

Comment 5

[Asaf Romano (gone)]

Comment on attachment 358873 [details] [diff] [review]
patch

The right fix is not to add the tab as a node-flavor.

Comment 6

[Dão Gottwald [:dao]]

Right. I don't see why replaceTabWithWindow should do anything if it's the only tab anyway. Doesn't seem useful.

Comment 7

[Nochum Sossonko [:Natch]]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090304 Minefield/3.2a1pre

Still happens here. requesting blocking.

Comment 8

[Nochum Sossonko [:Natch]]

Attachment: mano's suggestion

This is the patch mano had suggested, it's a trivial one-liner, I'm asking for ui-review because this changes the behavior of a tab drop on content with one tab open. In this case the browser will reload that tab like it did in 3.0. The problem is that if we remove all the flavors from the transfer you won't be able to do anything with the tab (i.e. drag to bookmarks, desktop, etc.).

The alternative approach from dao doesn't have this problem afaik, the behavior remains the same (i.e. nothing happens when you drop one tab on content).

Comment 9

[Nochum Sossonko [:Natch]]

Note: this also causes a bunch of warnings on a debug build.

Comment 10

[Asaf Romano (gone)]

Comment on attachment 365593 [details] [diff] [review]
mano's suggestion

Minusing my own suggestion, for both the issue you have rasied and due to the case of "merging" a window that has just one tab into some other window.

Comment 11

[Asaf Romano (gone)]

Comment on attachment 358873 [details] [diff] [review]
patch

This is probably "right enough", I would change the method name to mayReplaceTabWithWindow, but given that we're post most betas, just leave it as it is and document the strange behavior.

r=mano.

Comment 12

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/77a7aa432a4e

Comment 13

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

Comment on attachment 358873 [details] [diff] [review]
patch

a191=beltzner

Comment 14

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

Verified fixed on trunk with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090309 Minefield/3.2a1pre (.NET CLR 3.5.30729) ID:20090309032542

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

Comment 15

[Dão Gottwald [:dao]]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/42deaaf9c488

Comment 16

[Aakash Desai [:aakashd]]

verified FIXED on Shiretoko: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090513 Shiretoko/3.5b5pre ID:20090513034609