Track whether a scroll sequence has been partially prevented

ui/events/gesture_event_details.h

Index: ui/events/gesture_event_details.h
diff --git a/ui/events/gesture_event_details.h b/ui/events/gesture_event_details.h
index da7a60bef2a87217c6c4e0082f3230ee46c2be84..77381f7496f6a2bcbbcc1be7bcbe686313ca4651 100644
--- a/ui/events/gesture_event_details.h
+++ b/ui/events/gesture_event_details.h
@@ -130,6 +130,16 @@ struct EVENTS_BASE_EXPORT GestureEventDetails {
     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 {
@@ -144,6 +154,10 @@ struct EVENTS_BASE_EXPORT GestureEventDetails {
     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.