Actually what we want to do is to add a command line switch to disable the left stick smooth scrolling so that it can switch the functionality to traversal similar to the dpad for a gamepad. Is there a way to implement a command line switch for this?

Hi matthewn@, please see http://www.chromium.org/developers/contributing-code on how to contribute code. In summary, you should upload the issue to Reitveld, our code review system (http://codereview.chromium.org), add a reviewer (tdresser@ has reviewed that code in the past so he's a good candidate) and commit through that (you'll generally also need a test). Here's an example CL related to joystick code: https://codereview.chromium.org/1288243004

Since you're not a project member I can't assign this issue to you. I've parked it on tdresser@ in the mean time.

I'd be happy to review a change here, assuming we want this behavior.

What's the motivation here? The shield controller has a dpad as well. Are you trying to support multiple controller mappings?

So the original motivation here is that the gamepad enhancements for 'web page navigation' predated android TV, as well as the emergence of 'hybrid' apps.

Now we are finding there are a fairly decent number of high profile brands/companies shipping (or working with us to ship) HTML5 enabled ATV apps using system Webview.  The problem is our normal fallbacks for LS->DPAD (and A->enter, B->back) don't kick in due to default overrides for the 'web page nav' handling.

So yes, the motivation is multiple mappings, but more specifically the same set we recommend for NATIVE app devs (LS+DPAD same) should apply to hybrid apps.

I'm honestly not clear the 'right way' here.  If it was a year ago, I would have suggested a feature flag to enable the 'web page nav' support.  Where we are now with it as a default for better part of a year... well... my gut instinct says the easiest for developer relations interacting with the ISVs would be something like a manifest flag on the webview that sets the enable/disable state of 'web page nav' -- so devs can just set a flag in the manifest, and suddenly their app just works on SHIELD (because nobody handles the inputs, and our fallbacks kick in).

Did that all make sense?

By "web page nav" support, you're referring to scrolling via LS?

Hmmm, this probably wouldn't but it, but could we have LS manage focus for pages that aren't scrollable?

It sounds like this might involve a WebView specific solution, so assigning to aelias@.

It doesn't sound sane to overload left stick to sometimes scroll, and sometimes switch form field based on either heuristics or developer-managed policy (neither of which are intuitive for users).  How do native apps on Android behave?

Anyway, if Nvidia today prefers to generate synthetic touch or keyboard events at the system level for unhandled gamepad events, that's fine by me.  I'd be happy to just delete all the left-stick scrolling/zooming code, which was added by Nvidia in the first place [+sshelke@nvidia.com] and would reduce our code complexity.  We won't add a manifest flag for to toggle this, in general we don't add new WebView APIs lightly.

Sounds from offline discussions that no Chromium change is needed anymore for this.