Steps to reproduce: 1. Go to https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound 2. Scroll down all the way. 3. Click the "10" button to load more results. 4. Wait until the new results have loaded. Expected results: The new results should be visible. Actual results: The whole treeherder contents become blank. The header is still there, but the span.th-view-content is invisible / white. Switching away from the tab and back to it makes things reappear.

I can not reproduce this issue on Mozilla/5.0 (Windows NT 6.3; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0 the only issue I see is bug 1292781

INFO: Last good revision: c4449eab07d39e20ea315603f1b1863eeed7dcfe INFO: First bad revision: 5a4cdb6dfb19b458229c60e0e19f083ba83d0f58 INFO: Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c4449eab07d39e20ea315603f1b1863eeed7dcfe&tochange=5a4cdb6dfb19b458229c60e0e19f083ba83d0f58

It may very well be related to bug 1292781. Minimap has some interesting clues here. Not sure if the problem is with APZ, or more likely something is setting us into a very inconsistent state (where we are and where we think we are), so this is almost a checkerboard like situation.

Bug 1292781, which could be related (?) is blaming bug 1255968 as the regression source.

On Linux, I see bug 1292781, bug not this bug. The contents do disappear *briefly* after the scroll offset goes back to the top of the page, but they come back pretty quickly (with the scroll offset staying at (0, 0)).

Kats has a plan to fix bug 1292781 by re-writing some of the relevant code (see bug 1292781 comment 12). We should see if this bug still reproduces after that change.

This bug has the same underlying root cause as bug 1292781, as far as I can tell. The APZ and main thread get out of sync with respect to what the scroll position is - the APZ thinks it's at 0,0 and the main thread thinks it's at ~10000px or however long the initial page was. If something forces APZ to send a scroll position update to the main-thread, then all you see is a flicker and you end up back at 0,0 (i.e. bug 1292781). On OS X it seems like that doesn't happen, so you get stuck in the bad state indefinitely. The bad state is basically perma-checkerboarding, and also means you can't scroll using the trackpad because the APZ hit-test finds the root scrollframe rather than the actual scrollable subframe. That's probably something we should also fix. I also tried the patch I wrote for bug 1286179 and that didn't do the job, although from my initial investigation the scenario that induces this does seem very similar to what I described in bug 1286179 comment 8, at least from the APZ side of things. I suspect based on the regression range that on the main-thread side the scenario is triggered by interrupting a reflow, which might leave the bad scroll position dangling somehow. I'm digging into it further.

[Tracking Requested - why for this release]: Not being able to scroll. I'd consider this blocking 49.

This should be fixed by the patches I just landed for bug 1292781. I'll dupe this over once that merges to m-c.

Fixed up to 49 in the duplicate.