Track constant InputDeviceCapabilities objects per-window.

Track constant InputDeviceCapabilities objects per-window.

Do not keep global main thread Persistent<>s for the two
constant InputDeviceCapabilities objects, as that will
end up sharing wrapper objects across contexts.

R=dcheng
BUG=688569
Review-Url: https://codereview.chromium.org/2675793005
Cr-Commit-Position: refs/heads/master@{#448597}
Committed: https://chromium.googlesource.com/chromium/src/+/3867c9867bbb9bbe1d1d4c2c68b60073cb45caaf

[sof, 2017-02-04 15:09:34]

The CQ bit was checked by sigbjornf@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2017-02-04 15:09:43]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[sof, 2017-02-04 15:57:47]

sigbjornf@opera.com changed reviewers:
+ dcheng@chromium.org, esprehn@chromium.org, jochen@chromium.org

[sof, 2017-02-04 15:57:47]

please take a look.

The changes would be backportable without too much trouble, but I think we
should switch away from using InputDeviceCapabilities* internally and instead
just track it by some capability value/bitmask, which can then be instantiated
as an IDC* on demand. But that would be a bigger footprint change, and trickier
to merge.

[sof, 2017-02-04 15:57:59]

Description was changed from

==========
Record constant InputDeviceCapabilities per-window.

Do not keep global main thread Persistent<>s for the two
constant InputDeviceCapabilities objects, as that will
end up sharing wrapper objects across contexts.

R=
BUG=688569
==========

to

==========
Track constant InputDeviceCapabilities objects per-window.

Do not keep global main thread Persistent<>s for the two
constant InputDeviceCapabilities objects, as that will
end up sharing wrapper objects across contexts.

R=
BUG=688569
==========

[commit-bot: I haz the power, 2017-02-04 17:10:26]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-04 17:10:26]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build
URL)
  chromeos_amd64-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL)
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  chromium_presubmit on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build
URL)
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT,
no build URL)
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT, no
build URL)
  linux_chromium_tsan_rel_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT,
no build URL)
  win_chromium_compile_dbg_ng on master.tryserver.chromium.win (JOB_TIMED_OUT,
no build URL)
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_TIMED_OUT, no build
URL)
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_TIMED_OUT, no
build URL)
  win_clang on master.tryserver.chromium.win (JOB_TIMED_OUT, no build URL)

[esprehn, 2017-02-04 17:44:36]

What does the spec say for the lifetime of this object? Ex. Is it bound to the
window or each event?

[sof, 2017-02-04 18:08:13]

On 2017/02/04 17:44:36, esprehn wrote:
> What does the spec say for the lifetime of this object? Ex. Is it bound to the
> window or each event?

To the device,
http://wicg.github.io/InputDeviceCapabilities/#dom-inputdevicecapabilities

I assume "same" means object identity, which means that keeping it per-window
breaks the spec.

I wonder why value equality isn't adequate in practice; looping in rbyers@ and
lanwei@

[jochen (gone - plz use gerrit), 2017-02-04 18:12:45]

can you add a layout test?

[sof, 2017-02-04 20:56:21]

sigbjornf@opera.com changed reviewers:
+ lanwei@chromium.org, rbyers@chromium.org

[sof, 2017-02-04 20:56:22]

rbyers@, lanwei@: could you clarify the required lifetime of
InputDeviceCapabilities (see #9) ?

[sof, 2017-02-04 20:56:45]

On 2017/02/04 18:12:45, jochen (travelling til Feb 4) wrote:
> can you add a layout test?

done; but expected to fail per spec.

[sof, 2017-02-05 05:56:11]

The CQ bit was checked by sigbjornf@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2017-02-05 05:56:22]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-05 07:40:18]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-05 07:40:19]

Dry run: This issue passed the CQ dry run.

[jochen (gone - plz use gerrit), 2017-02-06 09:37:46]

(waiting for somebody to clarify the lifetime requirements)

[sof, 2017-02-06 10:53:46]

The CQ bit was checked by sigbjornf@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2017-02-06 10:53:56]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[sof, 2017-02-06 11:00:32]

On 2017/02/06 09:37:46, jochen wrote:
> (waiting for somebody to clarify the lifetime requirements)

The test now also checks .sourceCapabilities uniqueness across uses within a
window context, but pass conditions TBD.

[commit-bot: I haz the power, 2017-02-06 12:22:57]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-06 12:22:58]

Dry run: This issue passed the CQ dry run.

[lanwei, 2017-02-06 19:09:11]

On 2017/02/06 11:00:32, sof wrote:
> On 2017/02/06 09:37:46, jochen wrote:
> > (waiting for somebody to clarify the lifetime requirements)
> 
> The test now also checks .sourceCapabilities uniqueness across uses within a
> window context, but pass conditions TBD.

The InputDeviceCapabilities is one of the UIEvent's properties, and it has the
same lifetime as the event.

[sof, 2017-02-06 19:15:13]

On 2017/02/06 19:09:11, lanwei wrote:
> On 2017/02/06 11:00:32, sof wrote:
> > On 2017/02/06 09:37:46, jochen wrote:
> > > (waiting for somebody to clarify the lifetime requirements)
> > 
> > The test now also checks .sourceCapabilities uniqueness across uses within a
> > window context, but pass conditions TBD.
> 
> The InputDeviceCapabilities is one of the UIEvent's properties, and it has the
> same lifetime as the event.

That doesn't seem to be what the first para of
http://wicg.github.io/InputDeviceCapabilities/#the-inputdevicecapabilities-in...
is saying?

That para is the only motivation I can find for the assumed lifetime, that of
tying UIEvent.sourceCapabilities to an input device. i.e., it will allow event
sequences from a user interaction to be mapped back to one input device. (Sort
of, two input devices are actually allowed to report the same
InputDeviceCapabilities instance.)

The user interaction could in the general case span multiple windows or frames,
but I think I need a motivating example at this stage.

[Rick Byers, 2017-02-06 20:27:05]

On 2017/02/06 19:15:13, sof wrote:
> On 2017/02/06 19:09:11, lanwei wrote:
> > On 2017/02/06 11:00:32, sof wrote:
> > > On 2017/02/06 09:37:46, jochen wrote:
> > > > (waiting for somebody to clarify the lifetime requirements)

Sorry for the delay - BlinkOn craziness etc.

> > > 
> > > The test now also checks .sourceCapabilities uniqueness across uses within
a
> > > window context, but pass conditions TBD.
> > 
> > The InputDeviceCapabilities is one of the UIEvent's properties, and it has
the
> > same lifetime as the event.
> 
> That doesn't seem to be what the first para of
>
http://wicg.github.io/InputDeviceCapabilities/#the-inputdevicecapabilities-in...
> is saying?
> 
> That para is the only motivation I can find for the assumed lifetime, that of
> tying UIEvent.sourceCapabilities to an input device. i.e., it will allow event
> sequences from a user interaction to be mapped back to one input device. (Sort
> of, two input devices are actually allowed to report the same
> InputDeviceCapabilities instance.)

Yeah that was the original idea - the application might want to maintain a map
by InputDevice (and, in the future, be notified when input devices come and go).
 But when we moved to 'InputDeviceCapabilities' that became less obvious.  See
discussion here:
https://github.com/WICG/InputDeviceCapabilities/issues/19#issuecomment-128345456,
and the original API design sketch here:
https://docs.google.com/document/d/1WLadG2dn4vlCewOmUtUEoRsThiptC7Ox28CRmYUn8...

But I doubt it would be breaking to change this to say it's always a new object
if we think that's better for implementations (worst case we could introduce a
"device ID" field in the future or something).  If you think we should change
this, can you please file a spec issue so we can at least ping some of the
non-chromium folks involved in the design?

Can you please CC me on the bug so I can read it?  I'm curious to better
understand the issue.

[sof, 2017-02-06 21:35:06]

On 2017/02/06 20:27:05, Rick Byers wrote:
> On 2017/02/06 19:15:13, sof wrote:
> > On 2017/02/06 19:09:11, lanwei wrote:
> > > On 2017/02/06 11:00:32, sof wrote:
> > > > On 2017/02/06 09:37:46, jochen wrote:
> > > > > (waiting for somebody to clarify the lifetime requirements)
> 
> Sorry for the delay - BlinkOn craziness etc.
> 
> > > > 
> > > > The test now also checks .sourceCapabilities uniqueness across uses
within
> a
> > > > window context, but pass conditions TBD.
> > > 
> > > The InputDeviceCapabilities is one of the UIEvent's properties, and it has
> the
> > > same lifetime as the event.
> > 
> > That doesn't seem to be what the first para of
> >
>
http://wicg.github.io/InputDeviceCapabilities/#the-inputdevicecapabilities-in...
> > is saying?
> > 
> > That para is the only motivation I can find for the assumed lifetime, that
of
> > tying UIEvent.sourceCapabilities to an input device. i.e., it will allow
event
> > sequences from a user interaction to be mapped back to one input device.
(Sort
> > of, two input devices are actually allowed to report the same
> > InputDeviceCapabilities instance.)
> 
> Yeah that was the original idea - the application might want to maintain a map
> by InputDevice (and, in the future, be notified when input devices come and
go).
>  But when we moved to 'InputDeviceCapabilities' that became less obvious.  See
> discussion here:
>
https://github.com/WICG/InputDeviceCapabilities/issues/19#issuecomment-128345456,
> and the original API design sketch here:
>
https://docs.google.com/document/d/1WLadG2dn4vlCewOmUtUEoRsThiptC7Ox28CRmYUn8...
> 

Thanks, that clarifies - the conclusion from that seems to be a value-based view
of this extra event property.

> But I doubt it would be breaking to change this to say it's always a new
object
> if we think that's better for implementations (worst case we could introduce a
> "device ID" field in the future or something).  If you think we should change
> this, can you please file a spec issue so we can at least ping some of the
> non-chromium folks involved in the design?
> 

That these global instances serve as an unwanted conduit between origins, is the
main problem.

We could keep the UIEvent.sourceCapabilities IDCs shared per-window, or lazily
instantiated per event (https://codereview.chromium.org/2678683002/ moves to
such a design.) If backporting is needed, I think we have to go with a smaller
change like this CL first.

> Can you please CC me on the bug so I can read it?  I'm curious to better
> understand the issue.

Done, the issue came up via 687844.

[sof, 2017-02-07 06:45:00]

Given the above, I suggest we move forwards with what's here.

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

https://codereview.chromium.org/2675793005/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/http/tests/security/cross-frame-mouse-source-capabilities.html
(right):

https://codereview.chromium.org/2675793005/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/security/cross-frame-mouse-source-capabilities.html:8:
window.jsTestIsAsync = true;
Nit: can we write this using testharness.js?

https://codereview.chromium.org/2675793005/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/events/CompositionEvent.cpp (right):

https://codereview.chromium.org/2675793005/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/events/CompositionEvent.cpp:45: view ?
view->getInputDeviceCapabilities()->firesTouchEvents(false)
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]

https://codereview.chromium.org/2675793005/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/events/CompositionEvent.cpp (right):

https://codereview.chromium.org/2675793005/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/events/CompositionEvent.cpp:45: view ?
view->getInputDeviceCapabilities()->firesTouchEvents(false)
On 2017/02/07 06:53:04, dcheng wrote:
> 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...?

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]

https://codereview.chromium.org/2675793005/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/events/CompositionEvent.cpp (right):

https://codereview.chromium.org/2675793005/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/events/CompositionEvent.cpp:45: view ?
view->getInputDeviceCapabilities()->firesTouchEvents(false)
On 2017/02/07 07:08:58, sof wrote:
> On 2017/02/07 06:53:04, dcheng wrote:
> > 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...?
> 
> 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? 

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]

https://codereview.chromium.org/2675793005/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/events/CompositionEvent.cpp (right):

https://codereview.chromium.org/2675793005/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/events/CompositionEvent.cpp:45: view ?
view->getInputDeviceCapabilities()->firesTouchEvents(false)
On 2017/02/07 07:20:21, dcheng wrote:
> On 2017/02/07 07:08:58, sof wrote:
> > On 2017/02/07 06:53:04, dcheng wrote:
> > > 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...?
> > 
> > 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? 
> 
> 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|.

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

[sof, 2017-02-07 07:41:45]

https://codereview.chromium.org/2675793005/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/events/UIEvent.cpp (right):

https://codereview.chromium.org/2675793005/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/events/UIEvent.cpp:61:
initUIEventInternal(typeArg, canBubbleArg, cancelableArg, nullptr, viewArg,
Ah, all init*Event() get a null |sourceCapabilities|.

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

https://codereview.chromium.org/2675793005/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/http/tests/security/cross-frame-mouse-source-capabilities.html
(right):

https://codereview.chromium.org/2675793005/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/security/cross-frame-mouse-source-capabilities.html:8:
window.jsTestIsAsync = true;
On 2017/02/07 06:53:04, dcheng wrote:
> Nit: can we write this using testharness.js?

Done.

https://codereview.chromium.org/2675793005/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/events/CompositionEvent.cpp (right):

https://codereview.chromium.org/2675793005/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/events/CompositionEvent.cpp:45: view ?
view->getInputDeviceCapabilities()->firesTouchEvents(false)
On 2017/02/07 07:38:15, sof wrote:
> On 2017/02/07 07:20:21, dcheng wrote:
> > On 2017/02/07 07:08:58, sof wrote:
> > > On 2017/02/07 06:53:04, dcheng wrote:
> > > > 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...?
> > > 
> > > 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? 
> > 
> > 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|.
> 
> Yes, which is the more natural pairing. I'll switch the init*Event() methods
to
> consult the current (document) though.

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

[dcheng, 2017-02-07 09:14:40]

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

This CL LGTM. The part that makes me nervous is it'd be easy to introduce a
regression here in the future. It would be pretty easy to look at this code and
think that a natural cleanup would be to always derive the
InputDeviceCapabilities in the base class constructor...

https://codereview.chromium.org/2675793005/diff/60001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/http/tests/security/cross-frame-mouse-source-capabilities.html
(right):

https://codereview.chromium.org/2675793005/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/security/cross-frame-mouse-source-capabilities.html:27:
assert_true(evt.data === undefined);
FWIW, I think assert_equals already uses strict equality.

[sof, 2017-02-07 09:25:50]

On 2017/02/07 09:14:40, dcheng wrote:
> > Given https://codereview.chromium.org/2675793005/#msg33 , this issue has
been
> > addressed?
> 
> This CL LGTM. The part that makes me nervous is it'd be easy to introduce a
> regression here in the future. It would be pretty easy to look at this code
and
> think that a natural cleanup would be to always derive the
> InputDeviceCapabilities in the base class constructor...
> 

Yes, I suppose so. Switching to https://codereview.chromium.org/2678683002/ 's
internal handling of these capabilities, will centralize the decision of any
sharing of InputDeviceCapabilities* to the UIEvent::sourceCapabilities()
accessor.

[sof, 2017-02-07 09:29:57]

https://codereview.chromium.org/2675793005/diff/60001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/http/tests/security/cross-frame-mouse-source-capabilities.html
(right):

https://codereview.chromium.org/2675793005/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/security/cross-frame-mouse-source-capabilities.html:27:
assert_true(evt.data === undefined);
On 2017/02/07 09:14:40, dcheng wrote:
> FWIW, I think assert_equals already uses strict equality.

Switched to that idiom.

[sof, 2017-02-07 09:30:07]

Description was changed from

==========
Track constant InputDeviceCapabilities objects per-window.

Do not keep global main thread Persistent<>s for the two
constant InputDeviceCapabilities objects, as that will
end up sharing wrapper objects across contexts.

R=
BUG=688569
==========

to

==========
Track constant InputDeviceCapabilities objects per-window.

Do not keep global main thread Persistent<>s for the two
constant InputDeviceCapabilities objects, as that will
end up sharing wrapper objects across contexts.

R=dcheng
BUG=688569
==========

[sof, 2017-02-07 09:30:18]

The CQ bit was checked by sigbjornf@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2017-02-07 09:30:40]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-07 10:58:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-07 10:58:18]

Dry run: This issue passed the CQ dry run.

[sof, 2017-02-07 11:07:25]

The CQ bit was checked by sigbjornf@opera.com

[sof, 2017-02-07 11:07:26]

The patchset sent to the CQ was uploaded after l-g-t-m from dcheng@chromium.org
Link to the patchset: https://codereview.chromium.org/2675793005/#ps80001
(title: "test tidying")

[commit-bot: I haz the power, 2017-02-07 11:07:43]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-07 11:12:00]

CQ is committing da patch.

Bot data: {"patchset_id": 80001, "attempt_start_ts": 1486465645967920,
"parent_rev": "6dc672d93b3705ea017b2f538daa73408d970f7a", "commit_rev":
"3867c9867bbb9bbe1d1d4c2c68b60073cb45caaf"}

[commit-bot: I haz the power, 2017-02-07 11:12:36]

Description was changed from

==========
Track constant InputDeviceCapabilities objects per-window.

Do not keep global main thread Persistent<>s for the two
constant InputDeviceCapabilities objects, as that will
end up sharing wrapper objects across contexts.

R=dcheng
BUG=688569
==========

to

==========
Track constant InputDeviceCapabilities objects per-window.

Do not keep global main thread Persistent<>s for the two
constant InputDeviceCapabilities objects, as that will
end up sharing wrapper objects across contexts.

R=dcheng
BUG=688569

Review-Url: https://codereview.chromium.org/2675793005
Cr-Commit-Position: refs/heads/master@{#448597}
Committed:
https://chromium.googlesource.com/chromium/src/+/3867c9867bbb9bbe1d1d4c2c68b6...
==========

[commit-bot: I haz the power, 2017-02-07 11:12:37]

Committed patchset #5 (id:80001) as
https://chromium.googlesource.com/chromium/src/+/3867c9867bbb9bbe1d1d4c2c68b6...