Bug 1437694 - Gracefully recover from hit testing bugs affecting scrollbar dragging. r=kats

The recovery is only enabled for release builds, to avoid papering over
such hit testing bugs. On nightly builds, a diagnostic assert is issued.

MozReview-Commit-ID: Aos0j0jv6Lb

--HG--
extra : rebase_source : 1cb7fa24ed1f3cba7344f52670626bdeb41b51cc

gfx/layers/apz/src/InputBlockState.cpp

@@ -50,6 +50,26 @@ InputBlockState::SetConfirmedTargetApzc(const RefPtr<AsyncPanZoomController>& aT
     // can record the time for telemetry purposes.
     mTargetConfirmed = TargetConfirmationState::eTimedOutAndMainThreadResponded;
   }
+  // Sometimes, bugs in compositor hit testing can lead to APZ confirming
+  // a different target than the main thread. If this happens for a drag
+  // block created for a scrollbar drag, the consequences can be fairly
+  // user-unfriendly, such as the scrollbar not being draggable at all,
+  // or it scrolling the contents of the wrong scrollframe. In Nightly
+  // builds, we issue a diagnostic assert in this situation, so that the
+  // underlying compositor hit testing bug can be fixed. In release builds,
+  // however, we just silently accept the main thread's confirmed target,
+  // which will produce the expected behaviour (apart from drag events
+  // received so far being dropped).
+  if (AsDragBlock() &&
+      mTargetConfirmed == TargetConfirmationState::eConfirmed &&
+      aState == TargetConfirmationState::eConfirmed &&
+      mTargetApzc && aTargetApzc &&
+      mTargetApzc->GetGuid() != aTargetApzc->GetGuid()) {
+    MOZ_DIAGNOSTIC_ASSERT(false, "APZ and main thread confirmed drag block with different targets");
+    UpdateTargetApzc(aTargetApzc);
+    return true;
+  }
+
   if (mTargetConfirmed != TargetConfirmationState::eUnconfirmed) {
     return false;
   }