Track whether a scroll sequence has been partially prevented

ui/events/gesture_event_details.h

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef UI_EVENTS_GESTURE_DETECTION_GESTURE_EVENT_DETAILS_H_
 #define UI_EVENTS_GESTURE_DETECTION_GESTURE_EVENT_DETAILS_H_
 
 #include "base/logging.h"
 #include "ui/events/event_constants.h"
 #include "ui/events/events_base_export.h"
@@ skipping 112 matching lines @@
            type_ == ET_GESTURE_DOUBLE_TAP);
     data.tap_count = tap_count;
   }
 
   void set_scale(float scale) {
     DCHECK_GE(scale, 0.0f);
     DCHECK_EQ(type_, ET_GESTURE_PINCH_UPDATE);
     data.scale = scale;
   }
 
+  void mark_previous_scroll_update_in_sequence_prevented() const {
+    DCHECK_EQ(ET_GESTURE_SCROLL_UPDATE, type_);
+    data.scroll_update.previous_update_in_sequence_prevented = true;
+  }
+
+  bool previous_scroll_update_in_sequence_prevented() const {
+    DCHECK_EQ(ET_GESTURE_SCROLL_UPDATE, type_);
+    return data.scroll_update.previous_update_in_sequence_prevented;
+  }
+
  private:
   EventType type_;
   union Details {
     Details();
     struct {  // SCROLL start details.
       // Distance that caused the scroll to start.  Generally redundant with
       // the x/y values from the first scroll_update.
       float x_hint;
       float y_hint;
     } scroll_begin;
 
     struct {  // SCROLL delta.
       float x;
       float y;
+      // Whether any previous scroll update in the current scroll sequence was
+      // suppressed because the underlying touch was consumed. This is marked
+      // mutable as its value may be set downstream from event creation.
+      mutable bool previous_update_in_sequence_prevented;

[tdresser, 2014/11/10 21:51:01]

I'm not sure this is superior to making all the event passing non-const.

Do you think this is better?

[Rick Byers, 2014/11/10 22:03:08]

We hit a similar issue with touch-action, and there we decided that we should
mutate a copy of the event (passing non-const where needed), since that's really
what's happening in the system.  Using mutable and calling the events 'const'
seems like an abuse of the notion of 'const' to me.  What's the downside to
changing to non-const where necessary?

[jdduke (slow), 2014/11/10 22:23:43]

This is a very different case.

This extra bit I consider metadata. It gives additional context to the event,
but is not an integral part of the event's identity. For that reason, and that
the bit will (always?) be modified downstream from the event's creation, I feel
like mutable is a meaningful modifier.

Rick, your change fundamentally mutated the core of the event itself, so it
makes sense to mutate the event rather than make a few core members immutable.

I have similar plans with LatencyInfo: its modification should not require us to
copy an entire event, and I feel like making it mutable is a worthwhile
sacrifice to allow us keeping the associated event const.

[jdduke (slow), 2014/11/10 22:31:32]

Anyhow, if you guys prefer we not make this mutable, that's fine, I would just
copy the GestureEventData when necessary to modify the property...

     } scroll_update;
 
     float scale;  // PINCH scale.
 
     struct {  // FLING velocity.
       float x;
       float y;
     } fling_velocity;
 
     // Dimensions of the first finger's enclosing rectangle for
@@ skipping 21 matching lines @@
   // enclosing rectangles of the touch-points in the gesture.
   gfx::RectF bounding_box_;
 
   // The touch id of the oldest touch contributing to the gesture.
   int oldest_touch_id_;
 };
 
 }  // namespace ui
 
 #endif  // UI_EVENTS_GESTURE_DETECTION_GESTURE_EVENT_DETAILS_H_