Bug 1461122 - Ensure we recomposite when getting a main-thread scroll offset update. r=botond

With non-WebRender, the composite is triggered unconditionally when we receive
the transaction from the content side, so we never needed this. The previous
patch adds the composite for the equivalent WebRender codepath, but it's better
to do it explicitly in NotifyLayersUpdated as well. The reason for this is that
with WebRender, this code runs on the updater thread which is not the same as
the compositor thread - so the composition that is scheduled from
WebRenderBridgeParent upon receiving the transaction might happen before the
scroll offset update is actually applied. Triggering a composition from
NotifyLayersUpdated should be a no-op in the cases where a composition is already
scheduled, but in cases where it has not been scheduled, it will schedule one
to ensure the scroll offset update gets composited properly.

MozReview-Commit-ID: Luf76J6QDkr

--HG--
extra : rebase_source : a130f1cf22973910767e96c69962d8b621c0d368

gfx/layers/apz/src/AsyncPanZoomController.cpp

@@ -4184,6 +4184,9 @@ void AsyncPanZoomController::NotifyLayersUpdated(const ScrollMetadata& aScrollMe
       // Note that even if the CancelAnimation call above requested a repaint
       // this is fine because we already have repaint request deduplication.
       needContentRepaint = true;
+      // Since the main-thread scroll offset changed we should trigger a
+      // recomposite to make sure it becomes user-visible.
+      ScheduleComposite();
     } else if (scrollableRectChanged) {
       // Even if we didn't accept a new scroll offset from content, the
       // scrollable rect may have changed in a way that makes our local