Add navigator.maxTouchPoints

Add navigator.maxTouchPoints

Intent to implement-and-ship: https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/maxTouchPoints/blink-dev/ayzxdztUlOQ/rd-z_Jo3ocIJ

navigator.maxTouchPoints is defined in the W3C Pointer Events
standard draft:
http://www.w3.org/TR/pointerevents/#widl-Navigator-maxTouchPoints

BUG=248918
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=160153

[Inactive, 2013-10-17 21:03:42]

https://codereview.chromium.org/27750002/diff/1/LayoutTests/fast/dom/navigato...
File LayoutTests/fast/dom/navigator-maxTouchPoints.html (right):

https://codereview.chromium.org/27750002/diff/1/LayoutTests/fast/dom/navigato...
LayoutTests/fast/dom/navigator-maxTouchPoints.html:9:
document.write("navigator.maxTouchPoints == 37: " + (navigator.maxTouchPoints ==
37) + "<br>");
Would be nice to use js-test-pre.js / js-test-post.js framework and use:
shouldBe('navigator.maxTouchPoints', '37');

The following would also becomes unnecessary:
if (window.testRunner)
    testRunner.dumpAsText();

[Scott Blomquist (MS OPEN TECH), 2013-10-17 23:03:00]

On 2013/10/17 21:03:42, Chris Dumez wrote:
>
https://codereview.chromium.org/27750002/diff/1/LayoutTests/fast/dom/navigato...
> LayoutTests/fast/dom/navigator-maxTouchPoints.html:9:
> document.write("navigator.maxTouchPoints == 37: " + (navigator.maxTouchPoints
==
> 37) + "<br>");
> Would be nice to use js-test-pre.js / js-test-post.js framework and use:
> shouldBe('navigator.maxTouchPoints', '37');
> 
> The following would also becomes unnecessary:
> if (window.testRunner)
>     testRunner.dumpAsText();

Very helpful feedback--thanks. I think I've got now got the test case looking
more like what you were expecting.

[Rick Byers, 2013-10-18 21:04:04]

Note this was originally reviewed here:
https://codereview.chromium.org/20598008/

LGTM, thanks!

+abarth for owners in Source/web

[abarth-chromium, 2013-10-18 21:35:01]

Rather than adding this feature-specific code to the extremely general Navigator
object, can you put this in a supplemental interface?

Given that this is related to pointer events, perhaps this property should go in
a new Source/core/events/NavigatorEvents.idl partial interface?

[abarth-chromium, 2013-10-18 21:37:41]

On 2013/10/18 21:35:01, abarth wrote:
> Rather than adding this feature-specific code to the extremely general
Navigator
> object, can you put this in a supplemental interface?
> 
> Given that this is related to pointer events, perhaps this property should go
in
> a new Source/core/events/NavigatorEvents.idl partial interface?

You can look at other Navigator*.idl files in the modules directory to see how
this works.  You won't actually need to instantiate a supplement object.  You
can just get to the settings from the Navigator instance you'll be passed in the
first parameter.

[abarth-chromium, 2013-10-18 21:38:19]

Notice that using a partial interface matches how this is specced:

http://www.w3.org/TR/pointerevents/#extensions-to-the-navigator-interface

[Scott Blomquist (MS OPEN TECH), 2013-10-19 00:03:39]

On 2013/10/18 21:37:41, abarth wrote:
> On 2013/10/18 21:35:01, abarth wrote:
> > Rather than adding this feature-specific code to the extremely general
> Navigator
> > object, can you put this in a supplemental interface?
> > 
> > Given that this is related to pointer events, perhaps this property should
go
> in
> > a new Source/core/events/NavigatorEvents.idl partial interface?
> 
> You can look at other Navigator*.idl files in the modules directory to see how
> this works.  You won't actually need to instantiate a supplement object.  You
> can just get to the settings from the Navigator instance you'll be passed in
the
> first parameter.

Done.

[abarth-chromium, 2013-10-19 00:08:47]

LGTM w/ missing null checks.  Thanks for the CL!

https://codereview.chromium.org/27750002/diff/101001/Source/core/events/Navig...
File Source/core/events/NavigatorEvents.cpp (right):

https://codereview.chromium.org/27750002/diff/101001/Source/core/events/Navig...
Source/core/events/NavigatorEvents.cpp:43: return
navigator->frame()->page()->settings().maxTouchPoints();
You need to null-check both frame() and page() on this line.

[sblom, 2013-10-21 19:29:43]

On 2013/10/19 00:08:47, abarth wrote:
>
https://codereview.chromium.org/27750002/diff/101001/Source/core/events/Navig...
> Source/core/events/NavigatorEvents.cpp:43: return
> navigator->frame()->page()->settings().maxTouchPoints();
> You need to null-check both frame() and page() on this line.

Done.

Under what circumstances are they null? If it's possible for them to be null
under normal circumstances, I'll have to put more thought into the return values
when I abort due to null values.

[commit-bot: I haz the power, 2013-10-21 22:45:51]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/sblom@microsoft.com/27750002/151001

[commit-bot: I haz the power, 2013-10-22 08:43:39]

Change committed as 160153

[abarth-chromium, 2013-10-22 18:23:50]

On 2013/10/21 19:29:43, sblom wrote:
> On 2013/10/19 00:08:47, abarth wrote:
> >
>
https://codereview.chromium.org/27750002/diff/101001/Source/core/events/Navig...
> > Source/core/events/NavigatorEvents.cpp:43: return
> > navigator->frame()->page()->settings().maxTouchPoints();
> > You need to null-check both frame() and page() on this line.
> 
> Done.
> 
> Under what circumstances are they null? If it's possible for them to be null
> under normal circumstances, I'll have to put more thought into the return
values
> when I abort due to null values.

Some objects have relatively normal C++ object lifetimes (e.g., they're owned by
another object and get deleted at a defined time).  For other objects, we use
the V8 garbage collector to decide when to delete them.  In most code in Blink,
that boundary occurs at the Frame.  The Frame's lifetime is controlled by the
embedder and it dies at a defined time.  Objects "below" Frame, such as Document
and (in this case) Navigator have lifetimes controlled by V8 garbage collector.

To answer your question, the frame() points is null when the Navigator has
outlived the frame.  For example, if script in one frame grabs the navigator
property from a child frame and then removes that child frame from its DOM.  The
Frame object dies (at that defined time) but the Navigator object lives as long
as the script holds a reference to it.

The page() property is null for a brief period of time during Frame cleanup.  We
first detach the Frame from the Page (but nulling out the pointers going in both
directions), and then we start tearing down the Frame's objects, eventually
ending with deleting the Frame object itself.