Track constant InputDeviceCapabilities objects per-window.

third_party/WebKit/Source/core/events/CompositionEvent.cpp

Index: third_party/WebKit/Source/core/events/CompositionEvent.cpp
diff --git a/third_party/WebKit/Source/core/events/CompositionEvent.cpp b/third_party/WebKit/Source/core/events/CompositionEvent.cpp
index 3cf803375a01c0c7fb9524d1f0a36cfc6a13e878..60a041a57fc2b92bf2a1632e6d7ebe983ca3bb2e 100644
--- a/third_party/WebKit/Source/core/events/CompositionEvent.cpp
+++ b/third_party/WebKit/Source/core/events/CompositionEvent.cpp
@@ -26,6 +26,8 @@
 
 #include "core/events/CompositionEvent.h"
 
+#include "core/input/InputDeviceCapabilities.h"
+
 namespace blink {
 
 CompositionEvent::CompositionEvent() {}
@@ -33,15 +35,15 @@ CompositionEvent::CompositionEvent() {}
 CompositionEvent::CompositionEvent(const AtomicString& type,
                                    AbstractView* view,
                                    const String& data)
-    : UIEvent(
-          type,
-          true,
-          true,
-          ComposedMode::Composed,
-          TimeTicks::Now(),
-          view,
-          0,
-          InputDeviceCapabilities::doesntFireTouchEventsSourceCapabilities()),
+    : UIEvent(type,
+              true,
+              true,
+              ComposedMode::Composed,
+              TimeTicks::Now(),
+              view,
+              0,
+              view ? view->getInputDeviceCapabilities()->firesTouchEvents(false)

[dcheng, 2017/02/07 06:53:04]

My understanding is the |view| argument to things like initCompositionEvent()
can actually be a cross-origin object (see
https://developer.mozilla.org/en-US/docs/Web/API/CompositionEvent). So in this
case, wouldn't this expose a cross-origin InputEventCapabilities object?

Perhaps this needs to be tied to the current context...?

[sof, 2017/02/07 07:08:58]

I don't quite understand the semantics you're after -- if you've got access to a
|view|, why wouldn't you have access to its corresponding
InputDeviceCapabilities objects also? 

[dcheng, 2017/02/07 07:20:21]

It's possible to have access to a cross-origin window without having access to
most of the stuff inside that window.

So with something like this:

  var evt = document.createEvent('CompositionEvent').initCompositionEvent(
      '', false, false, crossOriginWindow, '');

then I think evaluating
  evt.sourceCapabilities

would return the sourceCapabilities associated with |crossOriginWindow|.

[sof, 2017/02/07 07:38:15]

Yes, which is the more natural pairing. I'll switch the init*Event() methods to
consult the current (document) though.

[sof, 2017/02/07 08:58:05]

Given https://codereview.chromium.org/2675793005/#msg33 , this issue has been
addressed?

+                   : nullptr),
       m_data(data) {}
 
 CompositionEvent::CompositionEvent(const AtomicString& type,