Able to reproduce the issue on Windows 10, mac 10.12.4 and Ubuntu 14.04 using chrome reported version #58.0.3029.110 and latest canary #60.0.3101.0 .

Bisect Information:
=====================
Good build: 55.0.2872.0  Revision(420859)
Bad Build : 55.0.2873.0  Revision(421052)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/38d12538c8af0b8afbf9c5b586b10902b9ba1303..ef06887f125941e96ab19fba834d9027d36d4c88

From the above change log suspecting below change
Review url: https://codereview.chromium.org/2358203002

schenney@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks...!!

This is probably due to my change, but revealing a bug that pre-existed.

Mouse scrolling works fine as does up/down arrow based keyboard scrolling. It is only Page Up/Down that breaks.

The background color changes to something transparent, so we stop compositing the scrolling div, and the root layer starts painting everything related to the scroller. For some reason, machinery necessary for handling Page Up/Down is not being associated with the demoted content - there is not even a layer there.

Over to the scroll team, or threaded rendering since this is a bug with layer status changes.

Actually, the up/down keys can break it to, it's just hard to see in the jsfiddle I gave. Here's a different one that's tweaked to make it easier to see the up/down key breaking the functionality. Just push down and you'll see it get's stuck one pixel down from the top where the color changes.

https://jsfiddle.net/o9pL959u/

Assigning to skobes@ for triage. Steve, I know we support handing off animations between main and CC, but that's for when scrolling is forced to one or the other - did we ever support the case where an animation starts on a CC layer which gets subsequently demoted? I have a feeling we just delete the animation in that case rather than handing it off to the main thread...

I think you're right.  The cc -> main takeover is triggered by adding main-thread scrolling reasons to the layer.  We don't do anything to handle the case of the layer going away.

I'm not sure why skobes unassigned this bug, but assigning to bokan@ to triage.

Marking untriaged so I remember to take a look at triage meeting tomorrow

This is a consequence of the fact that scrolling is so heavily tied to compositing. I think the approach for Scroll Unification should make this solvable in a satisfying way - since CC will be able to simply update the Node on the ScrollTree which wont go away and whether or not that causes an update to a "Layer" or just a reraster wont matter.

It's long term but I'm going to block on that.

Going on the description of cc-> main handover, and main scrolling blocking on unification it sounds like shorter fix would be main side too.  So: I'm removing this from cc hotlist.

Blocked on keyboard gesture scrolling