Switching tabs in Fennec-APZ sometimes doesn't update the metrics properly

RESOLVED INVALID

Status

()

Core
Panning and Zooming
RESOLVED INVALID
3 years ago
3 years ago

People

(Reporter: kats, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

STR:
1. Start fennec-apz (with the patch from bug 1200399 applied)
2. Load the page http://people.mozilla.com/~kgupta/griddiv.html
3. Try to scroll outside the div and observe that it doesn't scroll
4. Open a new tab and load the page http://people.mozilla.com/~kgupta/grid.html
5. Switch back to the first tab

Expected:
The page paints and doesn't scroll

Actual:
I'm finding that often the page doesn't paint at all, and if it does, it becomes scrollable

Logging the metrics on the java side seems to indicate that the java side still has the metrics from tab #2, even after switching back to tab #1. The mechanism for updating the java-side metrics is that on tab switch, the code at [1] sets the isFirstPaint flag on the presShell. On the following paint and layers transaction, that first-paint flag gets propagated to the compositor and the code at [2] should push it to Java. My logging shows that the code at [1] is running as expected but the code at [2] isn't for some reason, so the flag is getting lost somewhere along the way.

[1] http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js?rev=33817a41e2e1#1078
[2] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/composite/AsyncCompositionManager.cpp?rev=fb5a9ebbca96#650
The flag getting lost is also responsible for the page "not painting" because that flag is what triggers the call to LayerView::setPaintState and clears the background. I verified that without the flag reaching GeckoLayerClient, the LayerView is left in the PAINT_START state from [3] which means it just draws a solid background color rather than the content.

I also see this intermittently happening when I first start fennec-apz (i.e. the first page doesn't show up, because the mIsFirstPaint flag is getting lost and we never exit the PAINT_START state).

[3] http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/gfx/LayerRenderer.java?rev=5b05a359d909#657
This was just because of badness in my patch in bug 1200399, whoops.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.