1292613 - Treeherder contents disappear after loading new results

Status: RESOLVED DUPLICATE of bug 1292781

(Core :: Panning and Zooming, defect, P1)

Description

[Markus Stange [:mstange]]

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.

Comment 1

[Justin [:JW_SoftvisionQA]]

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

Comment 2

[Michelle Funches - QA]

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

Comment 3

[Milan Sreckovic [:milan] (needinfo for best results)]

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.

Comment 4

[Milan Sreckovic [:milan] (needinfo for best results)]

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

Comment 5

[Botond Ballo [:botond]]

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)).

Comment 6

[Botond Ballo [:botond]]

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.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 8

[Milan Sreckovic [:milan] (needinfo for best results)]

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

Comment 9

[Kartikaya Gupta (email:[e-mail])]

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

Comment 11

[Liz Henry (:lizzard) (relman/hg->git project)]

Fixed up to 49 in the duplicate.