Bug 1275604 - Ensure that we schedule a paint if the touch-action property changes. r=tnikkel draft
authorKartikaya Gupta <kgupta@mozilla.com>
Tue, 31 May 2016 09:23:34 -0400
changeset 373228 7cd1fbe9ef1a21204950b92af4ac513ac49dccd8
parent 373227 d7d13b87a11afa5f965d6fcdb7b7913cacee2919
child 373229 981f1b7b4f7f22bb025902d9c08222f7f890dacf
push id19715
push userkgupta@mozilla.com
push dateTue, 31 May 2016 13:53:56 +0000
reviewerstnikkel
bugs1275604
milestone49.0a1
Bug 1275604 - Ensure that we schedule a paint if the touch-action property changes. r=tnikkel MozReview-Commit-ID: 4gqFBm5ghrJ
layout/style/nsStyleStruct.cpp
--- a/layout/style/nsStyleStruct.cpp
+++ b/layout/style/nsStyleStruct.cpp
@@ -3086,16 +3086,22 @@ nsChangeHint nsStyleDisplay::CalcDiffere
                                NS_STYLE_WILL_CHANGE_OPACITY)) {
     hint |= nsChangeHint_RepaintFrame;
   }
 
   if (willChangeBitsChanged & NS_STYLE_WILL_CHANGE_FIXPOS_CB) {
     hint |= nsChangeHint_UpdateContainingBlock;
   }
 
+  // If touch-action is changed, we need to regenerate the event regions on
+  // the layers and send it over to the compositor for APZ to handle.
+  if (mTouchAction != aOther.mTouchAction) {
+    hint |= nsChangeHint_RepaintFrame;
+  }
+
   // Note:  Our current behavior for handling changes to the
   // transition-duration, transition-delay, and transition-timing-function
   // properties is to do nothing.  In other words, the transition
   // property that matters is what it is when the transition begins, and
   // we don't stop a transition later because the transition property
   // changed.
   // We do handle changes to transition-property, but we don't need to
   // bother with anything here, since the transition manager is notified