Closed Bug 474908 Opened 11 years ago Closed 11 years ago

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

Categories

(Firefox :: Tabbed Browser, defect, P2)

3.5 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 3.6a1

People

(Reporter: Natch, Assigned: dao)

References

Details

(Keywords: verified1.9.1)

Attachments

(2 files)

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.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090123 Minefield/3.2a1pre

Confirmed on the nightly.
Blocks: 471499
Status: UNCONFIRMED → NEW
Ever confirmed: true
That check should probably happen in tabbrowser's replaceTabWithWindow.
Also happens on OS X.
OS: Windows Vista → All
Hardware: x86 → All
Attached patch patchSplinter Review
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #358873 - Flags: review?(mano)
Comment on attachment 358873 [details] [diff] [review]
patch

The right fix is not to add the tab as a node-flavor.
Attachment #358873 - Flags: review?(mano) → review-
Right. I don't see why replaceTabWithWindow should do anything if it's the only tab anyway. Doesn't seem useful.
Assignee: dao → nobody
Status: ASSIGNED → NEW
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.
Flags: blocking-firefox3.1?
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).
Assignee: nobody → highmind63
Attachment #365593 - Flags: review?(mano)
Attachment #365593 - Flags: ui-review?(beltzner)
Note: this also causes a bunch of warnings on a debug build.
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.
Attachment #365593 - Flags: ui-review?(beltzner)
Attachment #365593 - Flags: review?(mano)
Attachment #365593 - Flags: review-
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.
http://hg.mozilla.org/mozilla-central/rev/77a7aa432a4e
Assignee: highmind63 → dao
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.2a1
Attachment #358873 - Flags: approval1.9.1?
Flags: blocking-firefox3.1? → blocking-firefox3.1+
Priority: -- → P2
Comment on attachment 358873 [details] [diff] [review]
patch

a191=beltzner
Attachment #358873 - Flags: approval1.9.1? → approval1.9.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
Status: RESOLVED → VERIFIED
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
You need to log in before you can comment on or make changes to this bug.