Safari has very nice behaviour when you drag a tab off to create a new window. First it animates to a thumbnail of the new window, then when the drag is released it animates an enlargement to the new window. It looks like this is implemented in Safari by creating the new window offscreen, with the tab reparented as soon as the drag begins. One piece of evidence that points to this behaviour is that the existing tab no longer updates while this is happening. The thumbnail also contains the new chrome. However, it looks like the page has not be reflowed, because the scroll bar does not extend all the way up to the new chrome which is shorter now because it lacks a tabstrip.

Oh, I guess this is different - that bug's just for normal tab drag/drop.

On a related note, there is a significant pause between releasing the button, having the dragged tab disappear and another pause before the new window actually appears. It makes you wonder if you threw tab away or if something bad happens. What are we doing during these pauses? Can we start doing it before the actual mouse release so that the latency of the tag drop is lower?

The process is basically to fire a whole bunch of events on the tab that's about to go away, then tear down the frame tree, build a new frame tree, and fire a whole bunch more events on the new tab. Depending on what extensions and chrome do with those events, you could see lag (though you'd see the same lag on page load/unload). Also, for large pages the frame tree operations could be significant. If you build on mac, this should be pretty easy to profile (and I can tell you how). If you don't, but have a particular page that shows the problem, I could probably profile for you.

I disabled all of the addons I had and the performance improved significantly, although faster would still be nicer. It looks like Ubiquity could be the cause of most of the problem. However, I'm on a mac and would like to see what's causing the slowdown. How would you recommend I profile it?

Assuming you're compiling yourself (per comment 4), the directions are at <https://developer.mozilla.org/En/Profiling_JavaScript_with_Shark>. The place to put the connectShark and startShark() calls is in the swapDocShells method of toolkit/content/widgets/browser.xml. Basically, connect and start at the beginning of the method, stop and end at the end of the method. That'll tell you what's going on on the C++/C/Objective-C level. Mapping that to the relevant JS if extensions are being the problem is always a little fun, unfortunately.

This does not prevent or restrict major functionality, and is not a regression, so not blocking on it. Would take a well-tested low-risk patch.

Could we change the title for searching purpose to "The tab tear-off (drag/new window) animation should be nicer." or maybe a better one "Implement animations for tab tear-off (drag/new window)" According to bug 455694#c33 : This bug should depend on bug 455694 (as 455694 covers reordering and tearing) The URL should mention : https://wiki.mozilla.org/Firefox/Projects/Tab_animation ;-)

Oops, I forget to add that according to bug 455694#c34 we should add [parity-ie] to the whiteboard ;-)

This has little to do with bug 455694, which is about the tab reordering animation. But I can't spot the difference between this and bug 485105 (improve tab-to-window experience). That one's younger, but has a lot of implementation comments and a wip patch, so duping to that.