Initial touch-action main thread implementation

public/web/WebWidgetClient.h

 /*
  * Copyright (C) 2009 Google Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are
  * met:
  *
  *     * Redistributions of source code must retain the above copyright
  * notice, this list of conditions and the following disclaimer.
  *     * Redistributions in binary form must reproduce the above
@@ skipping 154 matching lines @@
 
     // Returns true iff the pointer is locked to this widget.
     virtual bool isPointerLocked() { return false; }
 
     // Called when a gesture event is handled.
     virtual void didHandleGestureEvent(const WebGestureEvent& event, bool eventCancelled) { }
 
     // Called to update if touch events should be sent.
     virtual void hasTouchEventHandlers(bool) { }
 
+    // Called during WebWidget::HandleInputEvent for a TouchStart event to inform the embedder
+    // of the touch actions that are permitted for this touch.
+    enum TouchAction {
+        TouchActionNone = 0,
+        TouchActionAuto = 1
+    };
+    virtual void setTouchAction(int touchId, TouchAction touchAction) { }

[abarth-chromium, 2013/11/18 21:16:59]

Why a touchId?  Is there some sort of more structured object we could use
instead?  Perhaps WebTouchPoint?

Also, the TouchAction enum should probably be declared in the blink namespace,
likely in a new header.

[Rick Byers, 2013/11/19 21:24:21]

The touchid is the minimal data the embedder needs to correlate this call with a
particular finger.  The browser keeps a copy of all the outstanding
WebTouchPoint data (since we wouldn't want to trust what we get from the
renderer), so we just need an index into that data.  I think recreating a whole
WebTouchPoint from the pieces we have in WebCore would be a little silly since
we'd never want to trust any of that data in the browser.

But it turns out I'm not currently using this in chromium.  I had thought I
would, but we just agreed in the PE WG that the behavior here is sadly out of
scope of the spec (for IP reasons), so it's going to take a while longer to
decide how exactly we should handle it in Chrome.  For now I'm using a very
simple multi-point algorithm that doesn't need to correlate fingers.  

So how about I just omit this entirely from the API for now and worry about the
right encoding later if/when we decide we want a richer multi-pointer behavior?
Done.

+
 protected:
     ~WebWidgetClient() { }
 };
 
 } // namespace blink
 
 #endif