Closed Bug 989099 Opened 10 years ago Closed 10 years ago

[UX] Improve transition of subview panel

Categories

(Firefox :: Toolbars and Customization, defect)

x86
All
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 32

People

(Reporter: zfang, Assigned: bwinton)

References

(Blocks 1 open bug)

Details

(Whiteboard: [ux] p=3 s=it-32c-31a-30b.2 [qa-])

Attachments

(1 file)

Improve the transition to subview in the menu panel. Especially for subview that's long, like the history panel.
Whiteboard: p=0
Flags: firefox-backlog?
No longer blocks: fxdesktopbacklog
Flags: firefox-backlog? → firefox-backlog+
Summary: Improve transition of subview panel → [UX] Improve transition of subview panel
Whiteboard: p=0 → [ux] p=0
Whiteboard: [ux] p=0 → [ux] p=3
Assignee: nobody → bwinton
Status: NEW → ASSIGNED
Whiteboard: [ux] p=3 → [ux] p=3 s=it-32c-31a-30b.2 [qa?]
Attached patch bug989099.patchSplinter Review
So, the getFullHeight looked like a cause of a bunch of jank, due to a synchronous reflow, so I've moved it up before the transition so that it didn't interfere.

But.  I'm not sure how to test this.  Mike, could you re-purpose tart or something, to see if this is actually making a difference or not?

Thanks,
Blake.
Attachment #8421934 - Flags: feedback?(mconley)
Whiteboard: [ux] p=3 s=it-32c-31a-30b.2 [qa?] → [ux] p=3 s=it-32c-31a-30b.2 [qa-]
Perhaps we could also make the transition feel smoother by breaking it up into two animations?
1) slide in the sub view
2) expand the panel to the bottom
Philipp: We could, but I don't think that will be necessary.

The work we need to do now, as I see it, is:
1) Write a test to see how janky we are when entering a subview with a lot of items.
2) De-jank that transition, possibly using a variant of the patch I posted.
2a) Also look in to splitting up the animation, or whatever else we need to, if we can't get it smooth.

We may also want to change the summary of the bug to "De-jank the transition into and out of the subview panel."
(In reply to Blake Winton (:bwinton) from comment #1)
> Created attachment 8421934 [details] [diff] [review]
> bug989099.patch
> 
> So, the getFullHeight looked like a cause of a bunch of jank, due to a
> synchronous reflow, so I've moved it up before the transition so that it
> didn't interfere.
> 
> But.  I'm not sure how to test this.  Mike, could you re-purpose tart or
> something, to see if this is actually making a difference or not?
> 
> Thanks,
> Blake.

TART could likely be repurposed, like it was for the customization mode transition - but avih might be the better person to ask, since it's his baby.
Flags: needinfo?(avihpit)
Summary: [UX] Improve transition of subview panel → Improve transition of subview panel
Whiteboard: [ux] p=3 s=it-32c-31a-30b.2 [qa-] → p=3 s=it-32c-31a-30b.2 [qa-]
Summary: Improve transition of subview panel → [UX] Improve transition of subview panel
Whiteboard: p=3 s=it-32c-31a-30b.2 [qa-] → [ux] p=3 s=it-32c-31a-30b.2 [qa-]
See Also: → 1010275
Talking to :avih in IRC, he's on board with extending TART to do this.

Bug 1010275 filed for a performance test for the menu panel and subviews.

Not sure what the timeline would be to get that test written. Blake, are we willing to wait for the test to be written before landing this, so that we can do proper comparisons?
Sounds great. I've responded in bug 1010275 comment 1.
Flags: needinfo?(avihpit)
I'm resolving this fixed, since the UX part of the work is done.  Let's have a chat in the followup bug (or bugs ;).
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
(In reply to Mike Conley (:mconley) from comment #5)
> Not sure what the timeline would be to get that test written. Blake, are we
> willing to wait for the test to be written before landing this, so that we
> can do proper comparisons?

The enhancement of the addon could happen quickly, once I get what I need from you. This should be enough to use it locally as a development aid, and get instant feedback on code changes.

But if you mean waiting until talos start running this test regularly, then I wouldn't hold my breath. Typically, adding a new test for talos takes at least few weeks.
(In reply to Avi Halachmi (:avih) from comment #8)
> (In reply to Mike Conley (:mconley) from comment #5)
> > Not sure what the timeline would be to get that test written. Blake, are we
> > willing to wait for the test to be written before landing this, so that we
> > can do proper comparisons?
> 
> The enhancement of the addon could happen quickly, once I get what I need
> from you. This should be enough to use it locally as a development aid, and
> get instant feedback on code changes.
> 
> But if you mean waiting until talos start running this test regularly, then
> I wouldn't hold my breath. Typically, adding a new test for talos takes at
> least few weeks.

Hrm. Then I guess that means I'm the bottleneck here. :/ Fantastic.

Alright, lemme try to put together the pieces you need this afternoon. We'll continue over in bug 1010275.
Status: RESOLVED → VERIFIED
Target Milestone: --- → Firefox 32
Comment on attachment 8421934 [details] [diff] [review]
bug989099.patch

We haven't finished MART yet, so it's hard to determine whether or not this actually makes a difference to subview performance. I'm going to move this patch over to bug 1010275 where (someday?) we'll finish MART and can maybe test this.
Attachment #8421934 - Flags: feedback?(mconley)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: