Closed Bug 466196 Opened 16 years ago Closed 14 years ago

The tab tear-off/new window animation should be nicer.

Categories

(Firefox :: Tabbed Browser, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 485105
Tracking Status
blocking2.0 --- -

People

(Reporter: jrmuizel, Unassigned)

Details

(Whiteboard: [parity-safari] [parity-chrome] [parity-ie])

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.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Oh, I guess this is different - that bug's just for normal tab drag/drop.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Status: REOPENED → NEW
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.
blocking2.0: --- → ?
Blocks: 485105
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: [parity-safari] [parity-chrome]
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.
blocking2.0: ? → -
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 ;-)
Depends on: 596954
Blocks: 596954
No longer depends on: 596954
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.
No longer blocks: 485105, 596954
Status: NEW → RESOLVED
Closed: 16 years ago14 years ago
Resolution: --- → DUPLICATE
Summary: The tab drag/new window animation should be nicer. → The tab tear-off/new window animation should be nicer.
Whiteboard: [parity-safari] [parity-chrome] → [parity-safari] [parity-chrome] [parity-ie]
You need to log in before you can comment on or make changes to this bug.