http://go/chrome-androidlogs1/6/615152

Added files:
scrollpage.mp4
scrollpage.log

This states that it repros on M51.  I thought the other bug was 52+.  It would be realllllly sad to ship that on a stable release of 51.

OK, sorry, I didn't read carefully enough.  I can repro on http://www.wikipedia.org/ homepage on 50.0.2661.89 as well.  Cannot repro on amazon.com.  I checked in inspector and it wasn't immediately obvious what's unusual about that page.

Narrowed this down and produced a reduced test case: http://bokan.ca/bugs/615152.html

We prevent hiding the top controls when an editable node is focused. This seems to be intentional(ish) behavior, introduced by https://codereview.chromium.org/1209243003. Note, tapping off the text box and losing focus makes top controls hideable again.

I think the behavior's intent is to prevent hiding top controls when the OSK is shown but a proxy for that is to check if we have a focused text node. This, combined with the fact that we don't show the OSK when the page loads with a focused node (since it would be annoying on desktop pages that focus textboxes for convenience but don't necessarily imply the user wants to type), means that we end up with the buggy behavior.

We likely need a better way to determine if the OSK is showing. Assining to tedchoc@ for next steps.

Also, any reason this needs to be RVG?

OK, looks like the rationale for that change is tedchoc@'s comment in  http://crbug.com/504355  "If text can be entered (hardware or software keyboard), then the omnibox should not be hiding.  We would rather error on the side of overly-cautious".

I think we could make this more targeted by detecting the presence of a hardware or software keyboard, in addition to the textbox focus.  According to stackoverflow, we can detect the presence of a hardware keyboard with "getResources().getConfiguration().keyboard != Configuration.KEYBOARD_NOKEYS".

To handle this, we'd end up needing to bring back the old "best estimate" way of knowing the IME is showing along with the existing editable node is focused.

The editable node bit is the only way to handle hardware keyboards correctly.

The old IME state changed could be used for software keyboards.  But from the old patch, we didn't really have a good way for knowing whether the IME is actually showing (maybe changwan@ has learned some tricks to help)

Then we'd need to listen for configuration changes and if you attach/detach a hardware keyboard you need to tickle the fullscreen state.

OK.  We probably can find a better way today to detect software keyboard presence, if not with IME APIs, then ymalik@'s inset listener might be good enough.  We could also keep track of whether we requested a software keyboard.

Reassigning to myself for tracking.

Here are the list of the cases I can think of:

1) HW keyboard bound, autofocused or JS-focused --> can edit text
2) SW keyboard bound, autofocused or JS-focused --> keyboard not shown, cannot edit text
3) HW keyboard bound, touched editable node --> can edit text
4) SW keyboard bound, touched editable node --> keyboard shown, can edit text
5) SW keyboard bound, touched editable node, hide keyboard by press back --> keyboard not shown, cannot edit text

Approach A. keep the last SHOW/HIDE state, check the keyboard configuration, we can cover 1) thru 4).
Approach B. detect the actual keyboard show / hide state, we can cover 1) thru 5).

I'm not sure if we need to take approach B just to cover case #5. Is it worth the cost?

Assigning to changwan@ for backlog.  I think we should fix this eventually as I do notice the problem now and then, but we should do it in a clean way.