DDC issues in Chrome 86 due to changes in GamepadList

[sigmundch]

This seems to be causing issues in DDC downstream. Here is a sample repro:

import 'dart:html';
abstract class A {
  methodName() => print('hi');
}

class B extends A {
}

main() {
  print(window.navigator.getGamepads()); // ***
  (B() as dynamic).methodName();
}

The *** line is causing issues. Funny enough, the line itself produces no errors, but if you leave it, you get a nSM on the next line:

Uncaught Error: NoSuchMethodError: 'methodName'
Dynamic call of null.
Receiver: Instance of 'B'
Arguments: []
    at Object.throw_ [as throw] (errors.dart:213)
    at Object.defaultNoSuchMethod (operations.dart:721)
    at r1.B.new.noSuchMethod (core_patch.dart:61)
    at Object.noSuchMethod (operations.dart:716)
    at callNSM (operations.dart:255)
    at Object._checkAndCall (operations.dart:270)
    at Object.callMethod (operations.dart:388)
    at Object.dsend (operations.dart:392)
    at Object.main (repro.dart:12)

/cc @srujzs @nshahan

[sigmundch]

@Fox32 - are you using window.navigator.getGamepads() in the app that you mentioned in #43193 (comment)? Would the issue go away if you replace the use with JS-interop like:

@JS()
library example;

import 'package:js/js.dart';
...

@JS('window.navigator.getGamepads')
List<dynamic> getGamepads();

...
foo() {
   List<Gamepad> list = getGamePads().cast<Gamepad>();
   ...
}

[Fox32]

@Fox32 - are you using window.navigator.getGamepads()

@sigmundch Good catch, yes we are using it! I first tried to remove that part of the code and the no such method exception is gone! A bit strange is that the exception origins in code that totally not belongs to the code that is working with the gamepads 😆 But I guess that's how the DDC works internally. However this is still a good step, as I can work without gamepad support for now.

Second I tried your solution:

@JS()
library gamepad_polyfill;

import 'dart:html';

import 'package:js/js.dart';

@JS('window.navigator.getGamepads')
external List<dynamic> _getGamepads();

List<Gamepad> getGamepads() => _getGamepads().cast<Gamepad>();

I put it into a separate library and added the external keyword. However that fails with:

gamepad_polyfill.dart.lib.js:12 Uncaught TypeError: dart.global.window.navigator.getGamepads(...)[$cast] is not a function
    at Object.getGamepads (gamepad_polyfill.dart.lib.js:12)
    at game_loop_browser.GameLoopBrowser.new.[_processGamepadsEvents] (game_loop_browser.dart.lib.js:376)
    at game_loop_browser.GameLoopBrowser.new.[_processInputEvents] (game_loop_browser.dart.lib.js:288)
    at game_loop_browser.GameLoopBrowser.new.[_requestAnimationFrame] (game_loop_browser.dart.lib.js:446)

As I'm only interested in the first four values, I decided to go for this workaround for now:

@JS()
library gamepad_polyfill;

import 'dart:html';

import 'package:js/js.dart';
import 'package:js/js_util.dart';

@JS('window.navigator.getGamepads')
external dynamic _getGamepads();

List<Gamepad> getGamepads() {
  final gamepadList = _getGamepads();
  return [
    getProperty(gamepadList, '0'),
    getProperty(gamepadList, '1'),
    getProperty(gamepadList, '2'),
    getProperty(gamepadList, '3')
  ];
}

[franklinyow]

What is the status of this?

[srujzs]

I don't think there's been a fix to the API yet. There were other downstream effects of this broken API that affected DDC that were resolved by @Markzipan, but there's only the above workaround for this API for now.

[franklinyow]

Maybe this is a P2 now with the work around? If this is still a P1, we should schedule a it in a milestone.

[srujzs]

I'm fine with marking this as P2 for now, that's what we did on the internal facing bug as well.