The key icon (and the bar next to it) comes from the flag #passwords-keyboard-accessory.

It seems like twitter doesn't immediately react to the changed content area:
a) If you open the message, the keyboard accessory will overlay the input box.
b) If you swipe up, the message box will come into view, but with an offset.
c) If you close the keyboard, the message box will keep the offset.
d) If you swipe up again, the message box is at the same position as before a)

(Without a swipe, there will be no update to the message box or its offset.)

Deleted: twitter-overlaid.png 101 KB

	twitter-overlaid.png 101 KB View Download

Deleted: twitter-offset-keyboard.png 115 KB

	twitter-offset-keyboard.png 115 KB View Download

Deleted: twitter-offset-no-keyboard.png 62.9 KB

	twitter-offset-no-keyboard.png 62.9 KB View Download

When the keyboard comes up, window.innerHeight is resized from 660 -> 378 (on my N6). When I scroll and the input box comes up (second pic in #2), the window.innerHeight is resized from 378->274. The blank area between the input and keyboard is actually outside the document rect, and while it looks to be the same height as the password bar - it's actually a little larger. It turns out to be exactly the same size as the URL bar. The URL bar is forced to hidden in the PWA mode.

I printed out some of the resizes, it looks like the password bar is setting the bottom controls height and then setting browser_controls_shrink_blink_size. This is wrong since top controls still actually have a height so we shrink by both the password bar and the top controls. IHMO, the password bar doesn't make sense as a "bottom control" since that's really meant for controls that move with scroll. It should just increase the size of the keyboard when we resize the widget, is there a reason we chose to make it a "browser control"?

fhorschig@: it looks like you work on this feature, could you look into this?

Adding releaseblock-stable and P1 because it breaks keyboard input in a
big way for a top site. I'm assuming that this keyboard feature is not yet
rolled out to stable?

It's flag-guarded, not rolled out to Stable and Beta experiment is still pending. Please note: this issue is _only_ reproducible in PWA mode.

The keyboard bar is part of Chrome, not part of the keyboard, so (afaik), there is no way to affect the keyboard size for us. Unless this is different in PWA mode, then I would be incredibly grateful for any pointer :)
The current consent is: the accessory bar is (like the Duet toolbar) a control element at the bottom of Chrome that needs to affect the content area (by pushing it up to not overlay it). It should behave as an extension for the keyboard but is not part of it.

This feature is additive to Chrome and - although we definitely want it to be available in PWAs - it seems to make more sense to add PWA support later and disable the bar in PWA mode for now. I'll make sure to track progress on both.

In that case, the correct thing to do would be to resize the WebContents to fit the bar in below. I think that the password bar should be part of the Android Views layout, but I'm not too familiar with it. ChromeFullscreenManager.java has some of this code for the URL bar I believe but that's not the whole story. tedchoc@ might know more and where to look.

For now, I prepared a super short CL [1] to disable it and added it to the list of platforms to support (others are e.g. VR, Multi-Window, Hardware keyboards).

[1] https://crrev.com/c/1221531

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a6b624ee77677ab93685e8a82f6fbcac742a91d4

commit a6b624ee77677ab93685e8a82f6fbcac742a91d4
Author: Friedrich Horschig <fhorschig@chromium.org>
Date: Wed Sep 12 15:30:09 2018

[Android] Prevent keyboard accessory in PWAs

This CL aborts the initialization of the keyboard accessory if it is
requested for a WebappActivity. This effectively disables the accessory
in standalone PWAs.

Bug:  881536 
Change-Id: Ib98de07312051de7690c277f697e82a0474d0218
Reviewed-on: https://chromium-review.googlesource.com/1221531
Reviewed-by: Ioana Pandele <ioanap@chromium.org>
Commit-Queue: Friedrich Horschig [CEST] <fhorschig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#590689}
[modify] https://crrev.com/a6b624ee77677ab93685e8a82f6fbcac742a91d4/chrome/android/java/src/org/chromium/chrome/browser/autofill/keyboard_accessory/ManualFillingMediator.java

I thought this CL fixed it?

https://bugs.chromium.org/p/chromium/issues/detail?id=704070#c33

Or was that only in fullscreen mode?

That wasn't specific to the full-screen mode - it just made sure that the accessory wouldn't overlay contents anymore. In the linked bug, the input field would be overlayed instead of pushed up. Now, the content area is resized.

This bug has a similar look, but the underlying issue is different and very specific to PWAs: the content area is resized, but for some reason, the document window ignores that until another interaction happens (e.g. swiping up).

If these issues are connected, I haven't yet found out how. It seems, that they are connected though: if you run the sites in issue 704070 as PWA (with accessory disabled), the issue is gone.

I will track this in go/android-accessory-for-manual-ui#heading=h.h5d1h2rfj9tf and add new bugs for specific new steps in this direction. For now, I'm closing this bug as these repo steps don't apply to 71 anymore and I would want to merge it into 70.

This bug requires manual review: M70 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Approved for merge into 70, branch 3538.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4dc9366c4d09b14e40414ec436979ec1c2e72eeb

commit 4dc9366c4d09b14e40414ec436979ec1c2e72eeb
Author: Friedrich Horschig <fhorschig@chromium.org>
Date: Tue Sep 18 08:58:04 2018

[Android] Prevent keyboard accessory in PWAs

This CL aborts the initialization of the keyboard accessory if it is
requested for a WebappActivity. This effectively disables the accessory
in standalone PWAs.

Bug:  881536 
Change-Id: Ib98de07312051de7690c277f697e82a0474d0218
Reviewed-on: https://chromium-review.googlesource.com/1221531
Reviewed-by: Ioana Pandele <ioanap@chromium.org>
Commit-Queue: Friedrich Horschig [CEST] <fhorschig@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#590689}(cherry picked from commit a6b624ee77677ab93685e8a82f6fbcac742a91d4)
Reviewed-on: https://chromium-review.googlesource.com/1230035
Reviewed-by: Friedrich Horschig [CEST] <fhorschig@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#480}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
[modify] https://crrev.com/4dc9366c4d09b14e40414ec436979ec1c2e72eeb/chrome/android/java/src/org/chromium/chrome/browser/autofill/keyboard_accessory/ManualFillingMediator.java

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1e6e38295e5939b389f667e7a1b19311a11a6296

commit 1e6e38295e5939b389f667e7a1b19311a11a6296
Author: Friedrich Horschig <fhorschig@chromium.org>
Date: Thu Oct 11 16:24:41 2018

[Android] Decouple keyboard accessory from bottom controls

The multiple meanings with the bottom controls are a root for multiple
issues:
 * the CCT bottom bar being overlaid (and leaving a white patch)
 * the PWA bar resizing the viewport deferred
 * the flakiness of fullscreen applications

This CL introduces a solution that provides the bottom bars and the
compositor view holder with the "keyboard extension" as new bottom
element that is independent from others.

Currently, this extension is set on the instance. Long-term, the
delegate would only provide a getter that its children inherit.

Bug: 885113, 704070,  875077 , 891657,  881536 
Change-Id: I59639204823296b7c4ac701d0243aaa751f8b57d
Reviewed-on: https://chromium-review.googlesource.com/c/1233716
Commit-Queue: Friedrich Horschig [CEST] <fhorschig@chromium.org>
Reviewed-by: Matthew Jones <mdjones@chromium.org>
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Cr-Commit-Position: refs/heads/master@{#598792}
[modify] https://crrev.com/1e6e38295e5939b389f667e7a1b19311a11a6296/chrome/android/java/src/org/chromium/chrome/browser/ChromeActivity.java
[add] https://crrev.com/1e6e38295e5939b389f667e7a1b19311a11a6296/chrome/android/java/src/org/chromium/chrome/browser/autofill/keyboard_accessory/KeyboardExtensionSizeManager.java
[modify] https://crrev.com/1e6e38295e5939b389f667e7a1b19311a11a6296/chrome/android/java/src/org/chromium/chrome/browser/autofill/keyboard_accessory/ManualFillingCoordinator.java
[modify] https://crrev.com/1e6e38295e5939b389f667e7a1b19311a11a6296/chrome/android/java/src/org/chromium/chrome/browser/autofill/keyboard_accessory/ManualFillingMediator.java
[modify] https://crrev.com/1e6e38295e5939b389f667e7a1b19311a11a6296/chrome/android/java/src/org/chromium/chrome/browser/compositor/CompositorViewHolder.java
[modify] https://crrev.com/1e6e38295e5939b389f667e7a1b19311a11a6296/chrome/android/java/src/org/chromium/chrome/browser/customtabs/CustomTabBottomBarDelegate.java
[modify] https://crrev.com/1e6e38295e5939b389f667e7a1b19311a11a6296/chrome/android/java_sources.gni