465167 - Dragging a tab outside the current window to tear it off in a new one screws up tabs

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect, P1)

Description

[Matth78]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081115 Minefield/3.1b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081115 Minefield/3.1b2pre

Trying to tear off a tab in a new window result in a blank window with the tab still in the old one. Trying to close the tab is no longer possible.


Reproducible: Always

Steps to Reproduce:
1. Click on a tab and drag it to desktop (or windows bar)
2. a new blank window appears 
3. close the window
4. see that in original window the tab is still there and closing it is not possible

Comment 1

[Simon Bünzli]

Additional step to reproduce:
0. Set Firefox to _not_ "Always show the tab bar".

Comment 2

[Nochum Sossonko [:Natch]]

Requesting blocking as this is a big usability bug.

Comment 3

[Jim Jeffery not reading bug-mail 1/2/11]

Clicking the X to close the tab results in this error in the Console2:

Error: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebProgress.removeProgressListener]
Source file: chrome://browser/content/tabbrowser.xml
Line: 1456


Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081116 Minefield/3.1b2pre Firefox/3.0 ID:20081116112307 <-Latest Hourly
Vista HP SP1

Comment 4

[Asaf Romano (gone)]

Fixed by bug bug 463384.

Comment 5

[IU]

This bug cannot possibly be resolved.

I'm getting random cases of stuck tabs that can't be closed.  Attempts to close
it generate this exception:

Error: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE)
[nsIWebProgress.removeProgressListener]
Source file: chrome://browser/content/tabbrowser.xml
Line: 1509

I've experienced this both with the nightly and now the current hourly:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081118
Minefield/3.1b2pre ID:20081118181119

If can figure out a way to accurately reproduce, I will post steps.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

Bug 463384 was backed out...

Comment 7

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

Fixed by bug 471499

Comment 8

[Asaf Romano (gone)]

I don't think so, sorry.

Comment 9

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

Are you sure? As described in comment 0, this is WORKSFORME on OSX and w32. Now, instead, dragging to the desktop on OSX, w32 and linux creates shortcuts on the desktop instead of new windows ... but that feels like a separate bug, namely, bug 475066 which I just filed.

Comment 10

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

Verified too with the following trunk and 1.9.1 branch builds:

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

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

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

I believe it would be great to have a Litmus test for that issue, but we should probably wait for bug 475066.
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090123 Shiretoko/3.1b3pre Ubiquity/0.1.5 ID:20090123022451