Aaron Train [:aaronmt] Reporter
	Description • 10 years ago

See video http://people.mozilla.org/~atrain/mobile/jank-nexus6.mp4, cringe

	Jet Villegas (inactive)
	Comment 1 • 10 years ago

Profile shows a lot of time spent painting triggered by many style recalculations.

	Jet Villegas (inactive)
	Comment 2 • 10 years ago

Site uses the Orion menu framework for this animated menu (not jquery)
http://codecanyon.net/item/orion-responsive-menu/5268749

	Mike Taylor [:miketaylr]
	Comment 3 • 10 years ago

Here's the timeline profile I see on my phone--style recalculation is pretty long when I click on the hamburger or x to close it. Anywhere from 120 to 220ms.

	Mike Taylor [:miketaylr]
	Comment 4 • 10 years ago

When you click on the hamburger, it adds a "nav-open" class to the body element which triggers the following rules:

.wrapper{
	position:relative;
	margin-right:auto;
	margin-left:auto;
	min-height:100%
}

@media (max-width:7679px){
	body .wrapper{
		right:0;
		transition:.35s ease
	}

	body .wrapper:before{
		position:fixed;
		top:0;
		right:0;
		bottom:0;
		left:0;
		z-index:1;
		display:block;
		visibility:hidden;
		width:100%;
		height:100%;
		content:'';
		background-color:rgba(0,0,0,.5);
		opacity:0;
		transition:.35s ease
	}

	body.nav-open .wrapper{
		right:260px
	}

	body.nav-open .wrapper:before{
		z-index:2;
		visibility:visible;
		opacity:1
	}

	body.nav-open .site-nav{
		right:0
	}

}

At the same time the ".site-nav" is animated right:

@media (max-width:7679px){
	.site-nav{
		position:fixed;
		top:0;
		right:-260px;
		bottom:0;
		z-index:10;
		overflow-y:auto;
		width:260px;
		height:100%;
		background-color:#222;
		transition:.35s ease;
		-webkit-transform:translate3d(0,0,0);
		transform:translate3d(0,0,0);
		-webkit-overflow-scrolling:touch;
		-webkit-backface-visibility:hidden;
		backface-visibility:hidden
	}

}

So they're using this Orion thing (which uses jQuery), but only to listen for a click event and add a class.

	Mike Taylor [:miketaylr]
	Comment 5 • 10 years ago

("At the same time the ".site-nav" is animated right:" should probably say "these are the default values or site-nav".)

	Jet Villegas (inactive)
	Comment 6 • 10 years ago

The affected CSS animation is a transition from right:260px to right:0px which causes the style recalculation.

Markus: I doubt we can avoid the style recalculation, but the difference between the two timelines (mine is on Mac with Fennec user agent, Mike's is on Android) seems to point to something odd we're doing on Fennec. Can you have a look to see if we're doing something silly here?

	Jet Villegas (inactive)
	Comment 7 • 10 years ago

(In reply to Mike Taylor [:miketaylr] from comment #4)
> So they're using this Orion thing (which uses jQuery), but only to listen
> for a click event and add a class.

The developer of the Orion framework confirmed that this site doesn't actually use the Orion menu features. I updated the title again to reflect that.

	Markus Stange [:mstange]
	Comment 8 • 10 years ago

I think there's something wrong in general with the refresh driver on Fennec. I think I've seen a similar problem before, but unfortunately didn't file it.

	Aaron Train [:aaronmt] Reporter
	Comment 9 • 10 years ago

Equally as horribly slow the sidebar menu on play.google.com

	Markus Stange [:mstange]
	Comment 10 • 10 years ago

Debugging this took a while because Fennec profiling was broken, so I had to fix the profiler addon first.


There doesn't seem to be anything special going on in Fennec. We're doing the same work as in Desktop Firefox, it's just slower. And I don't understand why we're doing so much work in the first place.

Here's a profile, augmented with extra information for ElementRestyler::Restyle:
http://people.mozilla.org/~bgirard/cleopatra/#report=8e084236ea7042c57b5d4db7fd48605c06e7a794&filter=[{"type"%3A"RangeSampleFilter","start"%3A8036,"end"%3A9218}]&selection=0,1,8,9,2,462,463,464,465

Opening the sidebar animates the "right" property of div#top.wrapper by setting the class "nav-open" on the body. Here's the CSS code:

body .wrapper {
    right: 0px;
    transition: all 0.35s ease 0s;
}
body.nav-open .wrapper {
    right: 260px;
}

On every animation frame, we walk all descendants of the wrapper element and check whether their style has changed. There are a lot of elements so it takes a lot of time.

Cameron, why are we doing this? Are we trying to handle the case where a descendant inherits the value for "right" from .wrapper? Or is the animation of the "right" property not what causes us to spend so much time in restyling?

	Markus Stange [:mstange]
	Comment 12 • 10 years ago

Here's another profile with separate "Styles" markers in the timeline per ProcessOneRestyle:
> http://people.mozilla.org/~bgirard/cleopatra/#report=579e8dce7c787d02b648bcb9e9883653de427a76&filter=[{"type"%3A"RangeSampleFilter","start"%3A555,"end"%3A1685}]&selection=0,1,11,15,5,127,128,129,130,133,159

You can see that the first ProcessRestyles invocation includes two restyles: First, the restyle for the body + all descendants, and then the restyle for .wrapper + all descendants, even though .wrapper has been restyled as part of the body descendants restyle. (Hovering over the "Styles #1" box gives you a tooltip with the pseudostack under which RestyleTracker::AddPendingRestyleToTable was called.)

	Cameron McCormack (:heycam)
	Comment 13 • 10 years ago

Please try re-enabling the bug 931668 optimisation using the patch in bug 1125391 and seeing if that helps.

	Markus Stange [:mstange]
	Comment 14 • 10 years ago

It helps a lot!

Profile with that patch:
http://people.mozilla.org/~bgirard/cleopatra/#report=c9cfbc88ede48221a13f4c91dfa451645a1a5c6e&selection=0,1,519,23,498,499,508,514,515,536

The only remaining long restyle is the one at the very beginning, when the body's class is changed.

The animation still isn't very smooth, but now it's due to painting, and no longer due to restyles.

	Markus Stange [:mstange]
	Comment 15 • 10 years ago

Unassigning for now. With the patch for bug 1125391 this animation now has 5 or 6 frames instead of 1 or 2.
The slow painting is probably due to bug 1009693, which I still want to fix at some point but there's more important stuff to fix first.

	BMO Automation
	Comment 16 • 4 years ago

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.