bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

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

RESOLVED DUPLICATE of bug 485105

Status

()

Firefox
Tabbed Browser
RESOLVED DUPLICATE of bug 485105
10 years ago
5 years ago

People

(Reporter: jrmuizel, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(blocking2.0 -)

Details

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

(Reporter)

Description

10 years ago
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
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 455694
Oh, I guess this is different - that bug's just for normal tab drag/drop.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Status: REOPENED → NEW
(Reporter)

Comment 3

10 years ago
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.
(Reporter)

Comment 5

10 years ago
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.
(Reporter)

Updated

8 years ago
blocking2.0: --- → ?

Updated

8 years ago
Blocks: 485105
OS: Mac OS X → All
Hardware: x86 → All

Updated

8 years ago
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

Updated

8 years ago
Blocks: 596954
No longer depends on: 596954

Comment 10

8 years ago
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
Last Resolved: 10 years ago8 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]
Duplicate of bug: 485105
You need to log in before you can comment on or make changes to this bug.