From the internal bug it sounds like the "next field" button in the OSK should be behaving just like a TAB key, but on https://www.fcc.gov/ecfs/filings/express it's not. Perhaps that site is depending on the keyCode - and so this is  issue 118639 ?

I can't debug at the moment (on a plane with limited WiFi), but I wonder if this works in other Android (or iOS) browsers. I'm not sure how the next field button is represented in KeyboardEvents.

Hi there,

Asad from Techstop. I tested this in other android browsers using the gboard in the linked ticket from the org. description, here were my results:

Gboard (6.7.15.175732024-release-arm64-v8a - Pixel XL)
Mozilla Firefox Stable (57.0): works
Chrome Stable (62.0.3202.84): doesn't work
Chrome Beta (63.0.3239.60): doesn't work
Samsung Internet Stable (6.2.01.12): works
Dolphin Stable (12.0.2): doesn't work
UC Browser (11.4.8.1012): super annoying bloatware browser but works
Opera Stable (43.0.2246.121183): works

~ Asad

+changwan@ if he is aware of any fixed issues in this space.

I cannot reproduce this on a Nexus 5X (Chrome 63.0.3239.107, gboard 6.8.8.17814143-release-arm64-v8a or Chrome Canary 65.0.3292.0)

We changed this behavior at https://codereview.chromium.org/2967493002/, so no tab key event is generated.

At that time I thought that it does not make sense to depend on tab key event because users can send touch/mouse event to move to another form field.

But obviously there are such websites. The fix should be super simple, but we may need to clean up unused code path, if it might make sense to just send shift + tab for prev control case.

dtapuska@, I can work on this, but let me know if you're already working on it.

no please go ahead if you can

+Ajith

AFAIK, we are finding next focusable element by taking care of tab index. But only process text controls. If the next tab element is a non-text control, we are skipping it. In this way there will be difference in NEXT and TAB key behaviour. But I think that's expected. Am I missing something ?

Or else something like, we have to find tab focus and next focus (smart go next element) and if it differs (basically if it's not text control), then give priority to tab focus element to satisfy current website. If some checkbox, radio available it will gain focus instead of form. So actual benefit of Smart Go next will gets lost.

Could you pls give me access to the bug which is reported, so that i can get more clarity on current issue ?

Ticket # 29869083John Oliver encourages us to submit comments with the FCC
in support of internet neutraility (keeping ISPs under Title 2), and even
setup a website to sed you to the right place: gofccyourself.  If you
follow this link, see the one search result "Restoring Internet Freedom",
and click the small "+Express" you get to the form to file comments.
 If you try filling in the form on your android phone (in my case pixel 2),
you will discover that Chrome on android appears to not fill in the "name"
field correctly (it won't stick, it goes back to empty after enter/tab).
This is a a required field, and so IT APPEARS TO BE IMPOSSIBLE FOR AN
ANDROID PHONE USER TO SUBMIT A COMMENT SUPPORTING INTERNET FREEDOM.  This
is a serious problem IMHO.

Ajith, according to the report, this issue is happening on
https://www.fcc.gov/ecfs/filings/express
with Gboard.

Hmm... This is a difficult call. The webpage doesn't make much sense to me. It listens for a tab or enter key event, and creates a span to allow typing in multiple entries.

However, Gboard keyboard app does not provide tab nor enter key to start with. 
 Most mobile keyboards don't do that. We're simply emulating the tab key on the next action.

I think this is somewhat unusual and/or I'd say the webpage may not well-optimized.

Can someone test this out on iPhone?

rlanday@, could you help test this out on iPhone?

Safari for iOS also has buttons to go to the next/previous form field, and it has the same behavior as Chrome for Android. The yellow box is not added unless I explicitly press “return”. I think this bug is invalid.

It sounds that on Safari you have a way to explicitly press the return key.

However, I agree that this bug is invalid because it is Android's virtual keyboards who do not provide tab or enter key. There isn't much Chrome can do here. I've sent an email to the contact address from the website.