The Reader toolbar is a position: fixed element with bottom: 0px. In Beta (FF16) and Aurora (FF17) the toolbar stays on the same position while panning content (as expected). On latest Nightly though, the toolbar moves while panning. Need to find the regression range. Seems like a serious regression.

Seems to work now on latest nightly. Never mind.

In case this comes up again, to help bisect, a bad revision is 103641:271ca35d7645. I had a quick look at the layer tree, and async scrolling of fixed pos elements breaks because basically the entire layer tree is marked as fixed position, including the root scroll layer. This could indicate that either nsLayoutUtils::IsScrolledByRootContentDocumentDisplayportScrolling has been changed, nsLayoutUtils::GetActiveScrolledRootFor has changed, or the frame-tree has changed in some was so as to affect one or both of those two functions. The generated display-list is fine and correct.

Oh dear, so after stating that this wasn't my fault, I find that this is indeed my fault - This is caused by bug 785333, which just landed again. Looking into it.

I think this may have been caused by removing the code that swapped the underlying frame when merging in nsDisplayScrollLayer. Testing now.

This fixes the issue and I'm attaching it in case this needs to be urgently fixed, or developers would like to have this feature working for the time being. I'm going to look into why this happens and see if there's a more reliable way of working around it.

And here's a real patch to fix it. I think there may be a similar issue with other item types - I still see fixed-background breaking when zooming in (but this happened before any of these patches too), so it might be nice to find a more generic way of fixing this in all situations... Beats me what that way would be though, for now.

(In reply to Chris Lord [:cwiiis] from comment #6) > Created attachment 656547 [details] [diff] [review] > Fix getting the active scrolled root of an nsDisplayScrollLayer > > And here's a real patch to fix it. > > I think there may be a similar issue with other item types - I still see > fixed-background breaking when zooming in (but this happened before any of > these patches too), so it might be nice to find a more generic way of fixing > this in all situations... Beats me what that way would be though, for now. To illustrate the background issue, you can go to http://moonintern.com/, scroll while fully zoomed out, then zoom in slightly (but make sure the background is still visible) and then scroll. I see the same thing on various other sites too.

Pushed to inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/6a95de502ec1

This issue is not reproducing on: http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-inbound-android/1345819831/ but occurs on: http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-inbound-android/1345821510/ Here is the regression range for this issue: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7055bd788274&tochange=a1756976e61d

This issue is not reproducible anymore on the latest Nightly build. Closing as verified fixed on: Firefox 18.0a1 (2012-08-31) Device: Galaxy Note OS: Android 4.0.4

Comment on attachment 656547 [details] [diff] [review] Fix getting the active scrolled root of an nsDisplayScrollLayer [Approval Request Comment] Bug caused by (feature/regressing bug #): Merging bug 785333 but not this will break position:fixed async scrolling User impact if declined: Async scrolling of position:fixed elements will often break Testing completed (on m-c, etc.): Baked on m-c for a while, no complaints. Risk to taking this patch (and alternatives if risky): Low risk. String or UUID changes made by this patch: None.

Comment on attachment 656547 [details] [diff] [review] Fix getting the active scrolled root of an nsDisplayScrollLayer needed for 785333, approving.

Pushed to aurora: https://hg.mozilla.org/releases/mozilla-aurora/rev/b97cf7f8f87d