Delete WebGamepads::length.

Delete WebGamepads::length.

This field has only one use, the "i < gamepads.length" check in
NavigatorGamepad.cpp.  This check doesn't do anything useful and
actually introduces the following bug: if two gamepads are connected and
then the first one is disconnected, the second one remained at index 1
and was therefore dropped.  (There's no identifier for a gamepad other
than its index, so this bug can't be fixed by moving it to the beginning
of the WebGamepads structure.)

So I deleted the dynamic length and rely purely on itemsLengthCap
instead.

As a drive-by, add an initialization of displayId to 0 (was unset).

(This patch is an improved version of http://crrev.com/2457703002/)

BUG=648015
Committed: https://crrev.com/5367010cc54ad46dfa4cf535fd8e6527d4460891
Cr-Commit-Position: refs/heads/master@{#441503}

[aelias_OOO_until_Jul13, 2016-12-14 23:03:47]

The CQ bit was checked by aelias@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-14 23:04:23]

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

[aelias_OOO_until_Jul13, 2016-12-14 23:05:26]

aelias@chromium.org changed reviewers:
+ scottmg@chromium.org

[aelias_OOO_until_Jul13, 2016-12-14 23:05:56]

Hi scottmg@, PTAL since bajones@ is out on leave.  If this looks good to you,
I'll add additional OWNERS.

[commit-bot: I haz the power, 2016-12-14 23:07:24]

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

[commit-bot: I haz the power, 2016-12-14 23:07:25]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-device-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-xcode-...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)

[aelias_OOO_until_Jul13, 2016-12-14 23:21:49]

The CQ bit was checked by aelias@chromium.org to run a CQ dry run

[scottmg, 2016-12-14 23:22:13]

(Apparently WebGamepad has a constructor now!)

Can you add to this CL the initialization of WebGamepad::displayId there?

Will the removed entry will be null per
https://www.w3.org/TR/gamepad/#navigator-interface-extension with this change?

[commit-bot: I haz the power, 2016-12-14 23:22:44]

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

[aelias_OOO_until_Jul13, 2016-12-14 23:28:18]

Description was changed from

==========
Delete WebGamepads::length.

This field has only one use, the "i < gamepads.length" check in
NavigatorGamepad.cpp.  This check doesn't do anything useful and
actually introduces the following bug: if two gamepads are connected and
then the first one is disconnected, the second one remained at index 1
and was therefore dropped.  (There's no identifier for a gamepad other
than its index, so this bug can't be fixed by moving it to the beginning
of the WebGamepads structure.)

So I deleted the dynamic length and rely purely on itemsLengthCap
instead.

(This patch is an improved version of http://crrev.com/2457703002/)

BUG=648015
==========

to

==========
Delete WebGamepads::length.

This field has only one use, the "i < gamepads.length" check in
NavigatorGamepad.cpp.  This check doesn't do anything useful and
actually introduces the following bug: if two gamepads are connected and
then the first one is disconnected, the second one remained at index 1
and was therefore dropped.  (There's no identifier for a gamepad other
than its index, so this bug can't be fixed by moving it to the beginning
of the WebGamepads structure.)

So I deleted the dynamic length and rely purely on itemsLengthCap
instead.

As a drive-by, add an initialization of displayId to 0 (was unset).

(This patch is an improved version of http://crrev.com/2457703002/)

BUG=648015
==========

[aelias_OOO_until_Jul13, 2016-12-14 23:30:30]

The CQ bit was checked by aelias@chromium.org to run a CQ dry run

[aelias_OOO_until_Jul13, 2016-12-14 23:30:32]

On 2016/12/14 at 23:22:13, scottmg wrote:
> (Apparently WebGamepad has a constructor now!)
> 
> Can you add to this CL the initialization of WebGamepad::displayId there?

Done (initalized to 0).

> 
> Will the removed entry will be null per
https://www.w3.org/TR/gamepad/#navigator-interface-extension with this change?

Yes, into->set(i, 0); will still be called in NavigatorGamepad.cpp based on the
"connected" boolean being false.

[commit-bot: I haz the power, 2016-12-14 23:30:47]

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

[scottmg, 2016-12-14 23:32:21]

lgtm

[aelias_OOO_until_Jul13, 2016-12-14 23:36:46]

aelias@chromium.org changed reviewers:
+ pfeldman@chromium.org, raymes@chromium.org

[aelias_OOO_until_Jul13, 2016-12-14 23:37:14]

Adding OWNERS:

- pfeldman@ for components/test_runner/ and Source/modules
- raymes@ for ppapi/

[commit-bot: I haz the power, 2016-12-14 23:51:44]

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

[commit-bot: I haz the power, 2016-12-14 23:51:45]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[aelias_OOO_until_Jul13, 2016-12-15 00:04:19]

The CQ bit was checked by aelias@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-15 00:05:27]

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, 2016-12-15 00:26:51]

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

[commit-bot: I haz the power, 2016-12-15 00:26:52]

Dry run: Try jobs failed on following builders:
  chromeos_amd64-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)

[aelias_OOO_until_Jul13, 2016-12-15 01:09:48]

The CQ bit was checked by aelias@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-15 01:10:27]

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, 2016-12-15 01:16:05]

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

[commit-bot: I haz the power, 2016-12-15 01:16:06]

Dry run: Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)
  win_clang on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/...)

[aelias_OOO_until_Jul13, 2016-12-15 01:53:32]

The CQ bit was checked by aelias@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-15 01:53:47]

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, 2016-12-15 01:58:26]

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

[commit-bot: I haz the power, 2016-12-15 01:58:27]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[aelias_OOO_until_Jul13, 2016-12-15 02:55:25]

The CQ bit was checked by aelias@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-15 02:55:36]

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

[aelias_OOO_until_Jul13, 2016-12-15 03:05:27]

The CQ bit was checked by aelias@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-15 03:05:39]

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

[aelias_OOO_until_Jul13, 2016-12-15 03:18:11]

aelias@chromium.org changed reviewers:
+ reveman@chromium.org

[aelias_OOO_until_Jul13, 2016-12-15 03:18:22]

Also adding reveman@ for components/exo OWNERS

[raymes, 2016-12-15 04:14:48]

https://codereview.chromium.org/2572323002/diff/140001/ppapi/shared_impl/ppb_...
File ppapi/shared_impl/ppb_gamepad_shared.cc (right):

https://codereview.chromium.org/2572323002/diff/140001/ppapi/shared_impl/ppb_...
ppapi/shared_impl/ppb_gamepad_shared.cc:19: PP_GamepadSampleData& output_pad =
output_data->items[i];
Just to check - will output_data->items and webkit_data.items always have a
length of WebKitGamepads::kItemsLengthCap now? It's a bit unclear in this
function.

[aelias_OOO_until_Jul13, 2016-12-15 04:19:06]

https://codereview.chromium.org/2572323002/diff/140001/ppapi/shared_impl/ppb_...
File ppapi/shared_impl/ppb_gamepad_shared.cc (right):

https://codereview.chromium.org/2572323002/diff/140001/ppapi/shared_impl/ppb_...
ppapi/shared_impl/ppb_gamepad_shared.cc:19: PP_GamepadSampleData& output_pad =
output_data->items[i];
On 2016/12/15 at 04:14:48, raymes wrote:
> Just to check - will output_data->items and webkit_data.items always have a
length of WebKitGamepads::kItemsLengthCap now? It's a bit unclear in this
function.

Yes.  The data structures have always been statically sized to kItemsLengthCap
and initialized properly in the first place.

[raymes, 2016-12-15 04:32:22]

Thanks! lgtm

[commit-bot: I haz the power, 2016-12-15 04:37:28]

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

[commit-bot: I haz the power, 2016-12-15 04:37:30]

Dry run: This issue passed the CQ dry run.

[reveman, 2016-12-15 15:11:30]

reveman@chromium.org changed reviewers:
+ denniskempin@chromium.org

[reveman, 2016-12-15 15:11:31]

+denniskempin

components/exo lgtm

[aelias_OOO_until_Jul13, 2016-12-16 00:04:21]

OK thanks, just need pfeldman@ OWNERS on components/test_runner/ and
Source/modules

[aelias_OOO_until_Jul13, 2017-01-03 22:54:15]

aelias@chromium.org changed reviewers:
+ bajones@chromium.org, rbyers@chromium.org
- pfeldman@chromium.org

[aelias_OOO_until_Jul13, 2017-01-03 22:55:30]

OK, I'd like OWNERS approval from:
- bajones@ for Source/modules/gamepad
- rbyers@ for components/test_runner/

[bajones, 2017-01-03 22:58:36]

On 2017/01/03 22:55:30, aelias wrote:
> OK, I'd like OWNERS approval from:
> - bajones@ for Source/modules/gamepad
> - rbyers@ for components/test_runner/

scottmg@'s review should be sufficent for modules/gamepad, but LGTM anyway.

[Rick Byers, 2017-01-04 14:52:16]

test_runner LGTM

[aelias_OOO_until_Jul13, 2017-01-04 20:17:15]

The CQ bit was checked by aelias@chromium.org

[aelias_OOO_until_Jul13, 2017-01-04 20:17:16]

The patchset sent to the CQ was uploaded after l-g-t-m from
scottmg@chromium.org, reveman@chromium.org, rbyers@chromium.org,
raymes@chromium.org, bajones@chromium.org
Link to the patchset: https://codereview.chromium.org/2572323002/#ps160001
(title: "Rebase")

[commit-bot: I haz the power, 2017-01-04 20:17:39]

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-01-04 23:13:39]

CQ is committing da patch.

Bot data: {"patchset_id": 160001, "attempt_start_ts": 1483561035787210,
"parent_rev": "0c18e3feb55801d6ae78692b0c8250c83ec36954", "commit_rev":
"7690752a7559e8744ab87863bc1a1e4d3ee46970"}

[commit-bot: I haz the power, 2017-01-04 23:14:09]

Description was changed from

==========
Delete WebGamepads::length.

This field has only one use, the "i < gamepads.length" check in
NavigatorGamepad.cpp.  This check doesn't do anything useful and
actually introduces the following bug: if two gamepads are connected and
then the first one is disconnected, the second one remained at index 1
and was therefore dropped.  (There's no identifier for a gamepad other
than its index, so this bug can't be fixed by moving it to the beginning
of the WebGamepads structure.)

So I deleted the dynamic length and rely purely on itemsLengthCap
instead.

As a drive-by, add an initialization of displayId to 0 (was unset).

(This patch is an improved version of http://crrev.com/2457703002/)

BUG=648015
==========

to

==========
Delete WebGamepads::length.

This field has only one use, the "i < gamepads.length" check in
NavigatorGamepad.cpp.  This check doesn't do anything useful and
actually introduces the following bug: if two gamepads are connected and
then the first one is disconnected, the second one remained at index 1
and was therefore dropped.  (There's no identifier for a gamepad other
than its index, so this bug can't be fixed by moving it to the beginning
of the WebGamepads structure.)

So I deleted the dynamic length and rely purely on itemsLengthCap
instead.

As a drive-by, add an initialization of displayId to 0 (was unset).

(This patch is an improved version of http://crrev.com/2457703002/)

BUG=648015

Review-Url: https://codereview.chromium.org/2572323002
==========

[commit-bot: I haz the power, 2017-01-04 23:14:14]

Committed patchset #9 (id:160001)

[commit-bot: I haz the power, 2017-01-04 23:16:23]

Description was changed from

==========
Delete WebGamepads::length.

This field has only one use, the "i < gamepads.length" check in
NavigatorGamepad.cpp.  This check doesn't do anything useful and
actually introduces the following bug: if two gamepads are connected and
then the first one is disconnected, the second one remained at index 1
and was therefore dropped.  (There's no identifier for a gamepad other
than its index, so this bug can't be fixed by moving it to the beginning
of the WebGamepads structure.)

So I deleted the dynamic length and rely purely on itemsLengthCap
instead.

As a drive-by, add an initialization of displayId to 0 (was unset).

(This patch is an improved version of http://crrev.com/2457703002/)

BUG=648015

Review-Url: https://codereview.chromium.org/2572323002
==========

to

==========
Delete WebGamepads::length.

This field has only one use, the "i < gamepads.length" check in
NavigatorGamepad.cpp.  This check doesn't do anything useful and
actually introduces the following bug: if two gamepads are connected and
then the first one is disconnected, the second one remained at index 1
and was therefore dropped.  (There's no identifier for a gamepad other
than its index, so this bug can't be fixed by moving it to the beginning
of the WebGamepads structure.)

So I deleted the dynamic length and rely purely on itemsLengthCap
instead.

As a drive-by, add an initialization of displayId to 0 (was unset).

(This patch is an improved version of http://crrev.com/2457703002/)

BUG=648015

Committed: https://crrev.com/5367010cc54ad46dfa4cf535fd8e6527d4460891
Cr-Commit-Position: refs/heads/master@{#441503}
==========

[commit-bot: I haz the power, 2017-01-04 23:16:24]

Patchset 9 (id:??) landed as
https://crrev.com/5367010cc54ad46dfa4cf535fd8e6527d4460891
Cr-Commit-Position: refs/heads/master@{#441503}