From bug 898444: (In reply to Botond Ballo [:botond] from comment #4) > This page behaves very strangely on my Unagi device (latest m-c + latest > gaia), might be related: http://people.mozilla.org/~bballo/container.html I experimented a bit with similar pages and it appears that because the FrameMetrics.mCompositionBounds is always the size of the top-level document's composition bounds, the APZC for the subframe applies an async transform when it shouldn't be. Fixing bug 899100 should fix this.

So it looks like with the patch for bug 885023 applied this is fixed. Woo magic. I will do some more testing first.

Ignore comment 1. This was still happening. I figured out what was going on - basically the code in RecordFrameMetrics was always setting the mZoom and mResolution members of the frame metrics for subframes to the values for the top-level frame. In the world pre multi-APZC this didn't matter because those values were never read but now they are so they need to be corrected. The attached patch does the job but needs more testing. Note that the patch no longer gets the zoom from the TabChild, because that was causing iframes in the B2G browser to end up with the same zoom as the top-level frame (resulting the effective scale getting compounded). TabChild always calls setResolution correctly every time it updates mLastMetrics.mZoom anyway so we can just use the resolution and compute the zoom from that.

Comment on attachment 795635 [details] [diff] [review] Set mZoom and mResolution properly in RecordFrameMetrics Yeah, that makes since.

Updated to remove an unneeded function. Try push pending at https://tbpl.mozilla.org/?tree=Try&rev=5816aca51ea2

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #4) > Try push pending at > https://tbpl.mozilla.org/?tree=Try&rev=5816aca51ea2 Turns out I fail at pushing; I missed the actual patch in that push. I pushed again to try at https://tbpl.mozilla.org/?tree=Try&rev=a5c282e54875 and let it run until I was satisfied it was green enough, and then I aborted it. Landed on b2g-inbound: https://hg.mozilla.org/integration/b2g-inbound/rev/87eedd56640e

It looks like this may have regressed the tcheckerboarding benchmark by a lot http://mzl.la/15v4C7v

Looks like this caused a real regression in behaviour (which may or may not have caused the benchmark to regress). When zooming now it looks like the tile cache is completely thrown away and rebuilt. This doesn't really make sense to me but I'm investigating.

Apparently on Fennec we never enter RecordFrameMetrics with a scrollId of ROOT_SCROLL_ID. I see scrollIds of 0 and 3, but no 1. I'm guessing this is because of bug 732971, again.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #9) > Apparently on Fennec we never enter RecordFrameMetrics with a scrollId of > ROOT_SCROLL_ID. I see scrollIds of 0 and 3, but no 1. I'm guessing this is > because of bug 732971, again. Not necessarily directly related I would think at first glance. RecordFrameMetrics is about scroll layers, resolution is different from that.

I filed bug 912806 to track the regression. Moving discussion over there.