Having the very same issue on a HTML command line UI type application. The input text field is always at the bottom, and vertical screen space is super valuable so fullscreen mode is essential. Unfortunately, the command line is obfuscated by the soft keyboard in fullscreen mode.

Hi,

Resolving this issue is critical to my "text adventure game engine" type application working. This works fine on desktop OSs (without virtual keyboard), but on Android, it is terribly broken.

Please fix this issue. I have created a very good demonstration of this issue as described below.

Phone Used : Google Pixel 2
Operating System Used : Android 8.1.0; Pixel 2 Build/OPM1.171019.013
Browser Used : Chrome (Android) 63.0.3239.111

1) On an Android mobile phone (without hardware keyboard) ....
1) Navigate to http://eeyo.io/advdemo1
3) Click to start the adventure game.
4) Double clicking in the chrome window (double tap touch) will maximise the window (via an internal call to requestFullscreen() ) - because scrollable vertical space is REALLY important in text adventures. Ensure that the screen is now in fullscreen mode (NO NAV BUTTONS AT BOTTOM, no URL BAR AT TOP).
5) Now click the panel to put focus on the text input widget. 
6) OBSERVE, the bottom part of the play area is now not visible. 
7) Swipe up from the bottom of the screen.
8) Press Back Soft key (to exit full screen mode). Be careful not to double tap and re-enter full screen mode.
9) Click screen (single touch event). Now the software keyboard does not overwrite the bottom of the play area. The full play area is visible (but there is very little vertical space available.

A resolution to this bug should allow fullscreen mode to be used without hiding content behind the keyboard.

This bug has been open for 11 months now. Without a resolution to this bug, a mobile client that makes optimal use of screen space simply is not possible.

Correct Behaviour (in non fullscreen mode):

https://www.youtube.com/watch?v=B-k8mJ20ozY

Demonstration of 704070 bug (in fullscreen mode):

https://youtu.be/veE2LJgPXNI

Deleted: correct scrolling down to prompt.png 86.8 KB

	correct scrolling down to prompt.png 86.8 KB View Download

Deleted: keyboard obscuring prompt - no scrolling possible.png 88.0 KB

	keyboard obscuring prompt - no scrolling possible.png 88.0 KB View Download

Yeah, that seems pretty bad. I can't prioritize it in the next 2-3 weeks but I'll take a crack at it after that.

Ping!

Any progress on this one? It's a very annoying one indeed.

Though I don't know what change is responsible, the repro in #4 appears to be working for me in 69.0.3475.0 (Dev channel). Could you  please try dev channel on your own repro and see if that's working for you?

I just tried Canary Chrome 69, and the bug still exists. Please review.

Please can we have some progress on this issue ... I blogged about this issue (and other Android related vertical space issues) here : 

https://adventuron.blogspot.com/2018/07/the-battle-for-vertical-space-on-android.html

Sorry -- just got back from vacation. Interestingly, I can scroll around (and the bottom is scrolled into view when the OSK comes up) on my Pixel 2XL but not on my Nexus 6. I'll have to take a closer look tomorrow as to what the difference is.

Did you find the cause?

It looks like the element with class "gwtpromptlybackground" is resized (on my Pixel 2XL on Android P) and allows scrolling. On a Nexus 6 running Android N the page isn't resized (window.innerHeight doesn't change) so the container element isn't resized but is overlaid by the keyboard.

+tedchoc@ for Android, dtapuska@ for fullscreen. Do either of you know whether there's an Android API version difference for how views are resized when the OSK is shown while in fullscreen mode? Do we intentionally avoid resizing the RenderView? Is there someone on the Android side familiar with these APIs and the OSK?

Is this any different than:
https://bugs.chromium.org/p/chromium/issues/detail?id=519394

I (likely naively) thought that I addressed keyboard resizing when in fullscreen.

https://chromium.googlesource.com/chromium/src/+/c431cc9fb06b64d5eb6c269a54daba40babe534c/chrome/android/java/src/org/chromium/chrome/browser/compositor/CompositorViewHolder.java#262

But to be fair, I only tested on newer devices.  While in fullscreen, you don't get resize events, so you have to fake the sizing.

I was hoping that the InsetObserverView would handle this:
https://chromium.googlesource.com/chromium/src/+/c431cc9fb06b64d5eb6c269a54daba40babe534c/chrome/android/java/src/org/chromium/chrome/browser/compositor/CompositorViewHolder.java#380

But we should just see if that is being called as we expect on older versions.

Added a log there:

Log.w("chromium", "INSET CHANGED %d %d %d %d", top, left, bottom, right);

On Android N: INSET CHANGED 0 84 0 1155
On Android P: INSET CHANGED 0 0 0 1041

So it looks busted on N.

On a Pixel 2 device (running P - updated yesterday), running Canary Chrome, the problem is even worse. The keyboard covers the play area even when NOT in fullscreen mode.

https://eeyo.io/bonnie

Type : FULLSCREEN , for fullscreen mode

On the same device, with fully updated Chrome, normal mode is fine, but fullscreen still has the same bug reported in this issue.

For Canary, does the full keyboard cover the play area or only the row at the top with the lock icon in it?  There is a password UI that is being built that doesn't properly resize the content yet (+fhorschig).

Maybe upload a screenshot?

But it looks like we need to investigate the inset observer sadly :-/

[tedc...] Ok ... let me follow up.

Pixel 2

OK, I'm going to backtrack ... it seems to be working now.

I can 100% confirm I just a few hours ago witnessed the aforementioned behavior on Canary / Pixel 2 / Android P, but it appears that it may have been an older build, because I see that Android just informed me that a Canary update just installed, and the problem is not there in both fullscreen, and non-fullscreen mode. I had actually performed a Canary update to performing the previous test, but it's possible I performed the test before the update was applied (there were other updates). Anyway, my apologies, it DOES seem to be working with Pixel 2/ Android P / 3512+ build.

I don't know what the older build was, but the build on which the issue is resolved (for Pixel 2 / Android P) is build 70.0.3512.0 / OS Android 9.0.0;Pixel 2 Build/PPR1.180610.009.

I'm sorry for not 100% confirming the build number with the prior statement I made.

Moto E 4G

I tested out the 3512 canary build on the Moto E, which is running Android 6.0, and I can confirm, that this fullscreen issue is NOT resolved. It seems whatever is working for Pixel 2 (canary) is not working for other hardware. I will test on my Android tablet later today.

Deleted: MVIMG_20180808_000330.jpg 35.8 KB

	MVIMG_20180808_000330.jpg 35.8 KB View Download

Update, it is still not fixed (even on Pixel 2 / P / Canary 3512).

Please check new URL ... https://eeyo.io/bonnie2

It appears that the fullscreen problem is not fixed in this version of the fullscreen logic (this works on desktop & ios).

The prior link performed changed the style of the outer div of the content when going fullscreen. This new build simply calls the requestFullscreen() (or browser specific variant), to go fullscreen ... and it still fools Canary Build 3512 on Pixel 2 Android P.

So, I'd categorize this bug as "not fixed".

Assigning to tedchoc@ for triage since this appears to be an Android UI issue.

For https://eeyo.io/bonnie2 if I type FULLSCREEN, I just get a completely blank white page on canary.  It works on desktop, but I think there are some rendering craziness going on that that likely needs someone more familiar with the blink side of the world to know why it doesn't render what you see on desktop.

For now, the goal is to fix the inset observer to work on older builds.

Regarding comment #22 it fails in Chrome Canary, Dev and Beta as well. This is because we made some changes to make chrome more complaint with the fullscreen spec in terms of layerization.

The page is requesting document.documentElement.requestFullscreen() which causes a blank page. If document.body.requestFullscreen() is used instead it works correctly although I'm not sure why I need to debug that.

For the whitescreen issue the position with id="Ernest" is set to absolute but it if is set to Fixed it works correctly. Seems there is a variable running around in the program that controls whether it is fixed or absolute positioned.

Specifically this code:
                _.t = false;
                _.u = false;
                _.v = true;

If u is initialized to true it works correctly. Not sure what this variable does since it is obfusticated. Some of these fullscreen issues we've seen in the past are because things are written specifically around assumptions that Chrome's fullscreen mode is based on z-indicies which it no longer is.

TLDR version : I think this is still a Chrome bug, and it should still work with absolute positioning. Explanation for the positioning behavior is given below.


The code is designed to be used in two modes:

---------------------------------------
1) As a sub-div in a larger application
---------------------------------------

The explanation for why something can be "fixed" positioned at some times and "absolute" positioned at other times is best explained by (ON DESKTOP) navigating to http://eeyo.io/adv781 , execute the tutorial program, and double click the play area and you will see the outer div change its z order and positioning mode (between fixed and absolute). By using z order and changing the position of the game are div, I can toggle the game div to fill the whole screen, or just part of the screen (two panel view). I don't claim to be the world's greatest web developer, but this css has worked well on desktop for quite some time.



--------------------------
2) In a standalone application (where the div should consume all available space - minus optional border).
--------------------------

For STANDALONE compiled "text adventure" games (like https://eeyo.io/bonnie2 ), the panel is always using absolute positioning (but could use fixed positioning without side effect I suppose).

But I don't think that ABSOLUTE positioning should fail in such a way to be honest. For example, it works with as-is in Chrome desktop, and Microsoft Edge, and Safari. Either Chrome is wrong on desktop (where it works), or Chrome is wrong on mobile (where you get the blank screen).

It works neither on desktop or mobile for me using Canary, Beta or Dev channel. Hopefully foolip@ has an idea here. We should likely fork off the white screen issue into another issue as not to pollute this issue regarding the keyboard.

Copied issue chromium:704070 to  issue chromium:872368 

Thank you for paying attention to this issue ! You can see how long (the scrolling issue) has been going on. I feel so relived that this is being looked at. Going fullscreen is essential to players having a good experience.

One more thing, please can you ask the GBoard team if there is any plan to bring back the old behavior where the autocomplete bar above the keyboard was omitted when the autocomplete="off" attribute is specified. It's taking far too much vertical space. Strangely, this is being ignored in Chrome / Android now, but for Google's own search app (built into android), Google omits displaying the autocomplete bar (to make room for more results) - so it seems there is a private API that only Google can use, and not web developers. This seems unfair.

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

commit e7bce2b643b3c32470fcf20a98b7f9e510a2c791
Author: Ted Choc <tedchoc@google.com>
Date: Fri Aug 10 04:23:25 2018

Make fullscreen compositor sizing w/ keyboard work on Android < P.

The sizing is not perfect by any stretch though.  The size is
smaller by what appears to be the status bar height.  While
this is not ideal, it is still progressing towards being
actually usable.

BUG=704070

Change-Id: Ieae588fd9a5fc43b700adba399b86fb4e888349d
Reviewed-on: https://chromium-review.googlesource.com/1169976
Commit-Queue: Ted Choc <tedchoc@chromium.org>
Reviewed-by: Matthew Jones <mdjones@chromium.org>
Cr-Commit-Position: refs/heads/master@{#582051}
[modify] https://crrev.com/e7bce2b643b3c32470fcf20a98b7f9e510a2c791/chrome/android/java/src/org/chromium/chrome/browser/compositor/CompositorViewHolder.java

Just tried it on the new build of Canary, and it still goes blank if I go full screen, but in regular (non fullscreen, including URL bar) mode, the TOP and BOTTOM of the screen are also missing (before going fullscreen). This appears to be a regression. 

Also appearing are TWO unwanted autocomplete bars above the GBoard keyboard (when previously it was one). In short, it's a horrible user experience.

Deleted: Screenshot_20180813-204400_2.png 71.3 KB

	Screenshot_20180813-204400_2.png 71.3 KB View Download

Deleted: Screenshot_20180813-204811.png 127 KB

	Screenshot_20180813-204811.png 127 KB View Download

CC'ed nepper@ for element (2). We will check whether we can find a general solution to that but it sounds complicated.

About the scrolling: I am currently working on a CL to enable the scrolling for (2). Contents will then be pushed up as if it was part of the keyboard.

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

commit f7f385986a69d648d77b0b9f7821e7901df5c90f
Author: Friedrich Horschig <fhorschig@chromium.org>
Date: Fri Aug 17 08:00:41 2018

[Android] Make keyboard accessory views independent from BottomContainer

With this CL, the view stubs (and the views) are moved out of the
bottom container, which makes it possible (and necessary) to push up
all visible content.

This fixes:
 - the accessory overlaying page contents (esp. bad for fullscreen)
 - the accessory being pushed up by the keyboard (visual flickering)
 - clicking through the accessory

This changes:
 - the bar isn't pushed up by bottom sheets (like download) anymore BUT
   instead pushes them up when the bottom sheet is opened

Bug: 874257,  873591 , 704070,  853745 ,  865964 
Change-Id: I8185b1ac21aaaed3d7123855b8964a3f86c9845a
Reviewed-on: https://chromium-review.googlesource.com/1177361
Reviewed-by: Bernhard Bauer <bauerb@chromium.org>
Reviewed-by: Vaclav Brozek <vabr@chromium.org>
Commit-Queue: Friedrich Horschig <fhorschig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#583987}
[modify] https://crrev.com/f7f385986a69d648d77b0b9f7821e7901df5c90f/chrome/android/java/res/layout/keyboard_accessory.xml
[modify] https://crrev.com/f7f385986a69d648d77b0b9f7821e7901df5c90f/chrome/android/java/res/layout/keyboard_accessory_sheet.xml
[modify] https://crrev.com/f7f385986a69d648d77b0b9f7821e7901df5c90f/chrome/android/java/res/layout/main.xml
[modify] https://crrev.com/f7f385986a69d648d77b0b9f7821e7901df5c90f/chrome/android/java/src/org/chromium/chrome/browser/autofill/keyboard_accessory/AccessorySheetCoordinator.java
[modify] https://crrev.com/f7f385986a69d648d77b0b9f7821e7901df5c90f/chrome/android/java/src/org/chromium/chrome/browser/autofill/keyboard_accessory/AccessorySheetMediator.java
[modify] https://crrev.com/f7f385986a69d648d77b0b9f7821e7901df5c90f/chrome/android/java/src/org/chromium/chrome/browser/autofill/keyboard_accessory/KeyboardAccessoryCoordinator.java
[modify] https://crrev.com/f7f385986a69d648d77b0b9f7821e7901df5c90f/chrome/android/java/src/org/chromium/chrome/browser/autofill/keyboard_accessory/KeyboardAccessoryMediator.java
[modify] https://crrev.com/f7f385986a69d648d77b0b9f7821e7901df5c90f/chrome/android/java/src/org/chromium/chrome/browser/autofill/keyboard_accessory/KeyboardAccessoryMetricsRecorder.java
[modify] https://crrev.com/f7f385986a69d648d77b0b9f7821e7901df5c90f/chrome/android/java/src/org/chromium/chrome/browser/autofill/keyboard_accessory/KeyboardAccessoryModel.java
[modify] https://crrev.com/f7f385986a69d648d77b0b9f7821e7901df5c90f/chrome/android/java/src/org/chromium/chrome/browser/autofill/keyboard_accessory/KeyboardAccessoryView.java
[modify] https://crrev.com/f7f385986a69d648d77b0b9f7821e7901df5c90f/chrome/android/java/src/org/chromium/chrome/browser/autofill/keyboard_accessory/KeyboardAccessoryViewBinder.java
[modify] https://crrev.com/f7f385986a69d648d77b0b9f7821e7901df5c90f/chrome/android/java/src/org/chromium/chrome/browser/autofill/keyboard_accessory/ManualFillingCoordinator.java
[modify] https://crrev.com/f7f385986a69d648d77b0b9f7821e7901df5c90f/chrome/android/java/src/org/chromium/chrome/browser/autofill/keyboard_accessory/ManualFillingMediator.java
[modify] https://crrev.com/f7f385986a69d648d77b0b9f7821e7901df5c90f/chrome/android/javatests/src/org/chromium/chrome/browser/autofill/keyboard_accessory/ManualFillingIntegrationTest.java
[modify] https://crrev.com/f7f385986a69d648d77b0b9f7821e7901df5c90f/chrome/android/javatests/src/org/chromium/chrome/browser/autofill/keyboard_accessory/PasswordAccessorySheetViewTest.java
[modify] https://crrev.com/f7f385986a69d648d77b0b9f7821e7901df5c90f/chrome/android/junit/src/org/chromium/chrome/browser/autofill/keyboard_accessory/KeyboardAccessoryControllerTest.java
[modify] https://crrev.com/f7f385986a69d648d77b0b9f7821e7901df5c90f/chrome/android/junit/src/org/chromium/chrome/browser/autofill/keyboard_accessory/ManualFillingControllerTest.java
[modify] https://crrev.com/f7f385986a69d648d77b0b9f7821e7901df5c90f/chrome/browser/password_manager/password_accessory_controller.cc
[modify] https://crrev.com/f7f385986a69d648d77b0b9f7821e7901df5c90f/chrome/browser/password_manager/password_accessory_controller_unittest.cc

Confirmed on eeyo.io/bonnie2 that the content is now pushed up. The accessory is visible and the omnibox still consume quite some screenspace, but at least the content is scrollable so all contents can be seen an interacted with.

It does not appear fixed ( eeyo.io/bonnie2 ) in Chrome Canary Build 70.0.3529. I can't scroll all the way to the top or bottom, even in regular (non fullscreen mode), and if I go into fullscreen mode, the screen goes blank still. In short, it is unchanged.

Maybe this change hasn't propagated down to the canary build?

Deleted: Screenshot_20180821-162237.png 83.6 KB

	Screenshot_20180821-162237.png 83.6 KB View Download

My comment just referred to the lower bar mentioned in #31 and that it behaves as it should (pushing the content up instead of overlaying it). I haven't touched the fullscreen mode itself. Sorry if I sparked any false excitement :/

FWIW, I think the original premise of this bug is addressed in:
 https://chromium.googlesource.com/chromium/src.git/+/e7bce2b643b3c32470fcf20a98b7f9e510a2c791

It sounds like there issues around fullscreen turning the page white and potentially non-fullscreen, but those are no the original point of the bug.

Please file a bug for those separately, so we can properly triage them.

"My comment just referred to the lower bar mentioned in #31 and that it behaves as it should (pushing the content up instead of overlaying it). I haven't touched the fullscreen mode itself. Sorry if I sparked any false excitement :/"

In my test, on the 70.0.3529 build, the bug is not fixed, not even in regular (non fullscreen mode), in that the content cannot be fully seen, top and bottom, not even close.

So, my question was, is it supposed to be fixed in this canary build, or is it coming later?

"In my test, on the 70.0.3529 build, the bug is not fixed, not even in regular (non fullscreen mode), in that the content cannot be fully seen, top and bottom, not even close."

Meaning, I can't scroll up to the header line, or down to the textbox area.

Build 70.0.3529 is actually a regression when not entering fullscreen mode, because it appears impossible to see the top header line now, or to see the bottom of the text in the text pane, plus now fullscreen mode is 100% broken.

As requested, I filed this bug for the fullscreen blanking issue : https://bugs.chromium.org/p/chromium/issues/detail?id=876339&q=

This really is a critical bug for my product, as I simply can't ship on Android.

Demonstration of the culling of the top part of the screen at the START of this video (the fullscreen bug is shown later) :

https://youtu.be/cczpQ3a2zs0

I tested with canary version (3528) and scrolling down worked ... I could see all my inputs (which is what I intended to address).

So one more thing before I go: I had a quick look and noticed that your overall element height is usually relative to the viewport (vh units) but your margin and line heights are often absolute (e.g. the Hallway line is 20px). If you inspect this in Dev tools, you can quickly observe how screen density influences your desgin. Not sure whether your problem can be solved by using consistent units across all web ui elements and appropriate units for text sizes.

Please understand that I cannot find out any more details but I really hope you can come up with a solution. As tedchoc@ said, just file bugs for very specific issues and we can try to address them one by one.

Sorry, but the bug as described has not been fixed, because (as demonstrated in the youtube video) I still can't see the input field in fullscreen mode, so I can neither confirm nor refute that your fix works or not in fullscreen mode (which was the only mode in which the bug existed originally). That the input field was hidden in non fullscreen mode was something introduced post Chrome-68, and I agree, that issue is now resolved. But this issue, is "On screen keyboard breaks scrolling while using the fullscreen API", and as demonstrated, fullscreen mode is now broken, so maybe your non fullscreen mode fix worked in fullscreen mode, maybe it didn't, but it's not closed until it can be demonstrated in fullscreen mode.

I will raise another bug report for the related issue of not being able to see the top of the screen, and I have already raised an issue for the complete failure to render at all in fullscreen mode ( https://bugs.chromium.org/p/chromium/issues/detail?id=876339&q= ).

The sites I tested against in this bug:
https://bugs.chromium.org/p/chromium/issues/detail?id=519394
https://bugs.chromium.org/p/chromium/issues/detail?id=519394#c8

Were working at the time and I could validate the fix addressed it.  I definitely understand the frustration here, but I think the current issue is why the fullscreen content doesn't show up at all for your site.  The keyboard issue should be addressed.

I think it's still broke:

https://youtu.be/EQOixF4nAN4

When you click on the textfield ( https://virtualkeyboard-4bce7.firebaseapp.com/ ), it doesn't focus on the text field you just clicked on.

If you click on a field and the keyboard appears, then the field you just clicked on should be visible. It is not.

Plus,  issue 519394  is a PWA fullscreen issue, not a standard webpage Fullscreen API issue, so I'm not sure your test counts, because PWA fullscreen and the fullscreen lifecycle in standard web apps are not exactly the same.

I am really sorry about being so pedantic this, but it's taken a year to get any sort of focus on these issues, so I just want to be sure they are really going to be fixed.

IMPORTANT - THIS BUG IS NOT FIXED

I can confirm the original bug (keyboard obscures the main display area) is NOT FIXED on my Moto E2 device running on Android 6.0.0 (Canary 70.0.3532.0). It is precisely as shown in the video I posted in February : https://www.youtube.com/watch?v=veE2LJgPXNI&feature=youtu.be

Please review this change on a non pixel device.

Deleted: Screenshot_20180825-072626.png 40.5 KB

	Screenshot_20180825-072626.png 40.5 KB View Download

tedchoc@, can you take another look?

Again, that is a different issue.  The sole purpose of this bug was that the text field could not even be scrolled to.  The viewport of the page was not changed when the keyboard was shown in fullscreen.

Not autoscrolling to the text field is a separate issue and should be filed separately.  That is not an area I'm familiar with either so I will not be the candidate to investigate it.

c.b.ainsley@: please file a new bug and cc me on it, I'll investigate the autoscrolling behavior.

"Again, that is a different issue.  The sole purpose of this bug was that the text field could not even be scrolled to.  The viewport of the page was not changed when the keyboard was shown in fullscreen."

With all due respect, this bug is NOT fixed. Please see the video ( https://www.youtube.com/watch?v=veE2LJgPXNI&feature=youtu.be ). The original bug (that the keyboard obscures the play area in fullscreen mode) is NOT FIXED. Please watch the video, and pay attention that I am using a very recent Canary version in the video.

I agree the bug is fixed on Pixel 2 / Android 9, but the bug should be fixed for other devices too.

I can confirm the issue still exists but is now flaky - sometimes the screen will be scrollable (and then I see graphical glitches), sometimes it wont. Seems I can repro about 3/5 times but it's streaky, it'll work 3-4 times in a row, ten fail a few times in a row. My steps (not sure how much of it is required vs superstition but this results in a fairly consistent repro for me):

1) Open https://eeyo.io/advdemo1
2) Tap once on the "ADVENTURON" screen (keyboard comes up)
3) Tap once on the "you must drive to work" screen
4) On the "Hallway" screen, fling all the way to the top
5) Fling all the way to the bottom
6) Double tap to enter fullscreen

Chrome 70.0.3535.2 (so fix in #33 is included). Nexus 6 running Android N. Here's a video

Deleted: osk.mp4 9.9 MB

	osk.mp4 9.9 MB View Download

Any movement on this?

Unfortunately not.  This was broken for many years (since the launch of fullscreen honestly) and we haven't gotten much feedback on it, so it is not a high priority to dig into the wonkiness of every Android platform to try and suss out what is going on.

It's something I try to chip away at when I have cycles, but I've had too many things interrupt me to make any meaningful progress.

Some temporary good news: Your site works as PWA. (So, if I add your site to the homescreen, it works fullscreen.)

The feature I am currently working on might be related to your issue. I will update this bug as soon as there is any change. (I can't make any promises about timelines but this seems to be part of a bigger issue, so it _is_ getting fixed and I _will_ push updates.)

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

Works for me on trunk. The next Canary should have the fix (version > 71.0.3577).

This bug is still not fully fixed in all contexts ....

I have witnessed this issue on my HTML5 application, The Beast ( https://adventuron.itch.io/thebeast ), and it makes the whole thing feel very broken.

To make it easier to diagnose, I isolated the bug and built a simple PWA to demonstrate it (seems to be triggered in PWA fullscreen mode more than webpage fullscreen mode - which I believe is due to a timing issue on the fullscreen event).

Here are the steps to replicate the bug (as shown in the video).

1. Using Android Chrome (stable version 71).
2. Navigate to https://adventuron.io/chromebugs/thornaby
3. Notice that there are 22 paragraphs. Underneath the paragraphs there is a div containing an input widget.
4. Click the install as PWA button.
5. Now close the tab in the browser.
6. Now run the "Thornaby" webapk on your android app drawer / home screen.
7. (this part is intermittent). The body element has an onclick event associated with it. Clicking inside the body, will call scrollIntoView() then focus() on the input element (scroll down to the bottom of the screen and bring up the software keyboard).
8. Keep reloading the Thornaby webapk and click inside the frame to trigger the onclick event, then, it may not allow you to scroll to the bottom of the content panel. It took 6 tries, but I made a demonstration of it today (Chrome version 71.0.3578.99 Stable / Android 9 / Pixel 2 Build/PQ1A.181205.002).

https://www.youtube.com/watch?v=y3A0cmKUKjQ

I think that there is a timing issue on the appearance of the keyboard where if the screen is scrolling at the same time that it somehow chops off the height of the keyboard from the content area.

Which is to say, this issue is still live and in need of a robust solution.

Looks hard to reproduce and easy to escape, and seems quite different from the earlier issues (in terms of which component is affected).

Still, reopening so we don't lose sight of this.

Thanks for re-opening.

It's easy enough to reproduce if you follow the technique listed, although of course, it's not 100% because there appears to be a timing/threading element to this issue.

I'd say it's difficult to escape, because a regular user wouldn't be able to manually exit full screen mode, cancel the keyboard, bring the keyboard back up, and scroll. Especially if this is happening once every minute of gameplay (this issue affects gameplay - which uses text input).

You can see this issue in action by installing the PWA here : 

https://adventuron.io/games/thebeast

The PWA will save the state of the screen, so enter a few inputs so that the screen is full, then swipe away the PWA on the android task manager. This will save the state of the screen. Next, reload "The Beast" PWA, and sometimes the bottom of the screen will not be able to scrolled with - it tends to be if you click the screen quickly after reload.

It certainly appears to be a timing related issue.

As "The Beast" is very complex, the "thornaby" mini example should be good enough to test against.

Just pinging this issue, I would like this resolved if at all possible, because as it stands, it's extremely difficult to ship a PWA commercially with this bug outstanding. Also, this issue (including the earlier variation) is approaching  two years old now.