New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 4 users

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug

Sign in to add a comment

Issue 704070: On screen keyboard breaks scrolling while using the fullscreen API

Reported by, Mar 22 2017

Issue description

Steps to reproduce the problem:
1. Open the attached html files in Chrome for Android.

2. First example displays an input field aligned to the bottom of the page. If you tap it, onscreen keyboard will be displayed and the view will be resized so the input field will be shown above the onscreen keyboard. However, if you switch into fullscreen mode using the HTML5 fullscreen API and tap the input field, then it will be hidden behind the onscreen keyboard.

3. The second example displays many input fields. If you tap any of them near the bottom of the screen then it will be scrolled into view and shown above the onscreen keyboard. However, after switching into fullscreen mode when you tap the  input field it will be hidden behind the onscreen keyboard. Moreover, the view cannot be scrolled (dragged) to make the focused input field visible.

So there are two issues in fullscreen mode when onscreen keyboard is visible: the view's size is not updated and it cannot be scrolled.

What is the expected behavior?
Onscreen keyboard shouldn't hide the focused input field.

What went wrong?
Onscreen keyboard hides focused input field because the viewport's dimension is not updated AND it cannot be scrolled.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 56.0.2924.87  Channel: stable
OS Version: 5.1.1
Flash Version: 

This issue is similar to  issue 453259 , but this is related to the Fullscreen API while  issue 453259  is related to webapps (standalone mode). That's why I was told to file this as a new issue.

Use cases:
HTML5 games use the fullscreen API to provide better user experiment. Fullscreen API is required even in webapps, because webapps currently start in standalone mode (status bar still visible).
HTML5 games might need text input for various reasons: user registration, character customization, in-game chat etc.
HTML5 game can be canvas based or built from regular HTML components (for instance a sports manager game does not need custom canvas GUI).

Exit fullscreen mode if an input field receives focus / restore fullscreen mode if focus is lost (bad user experience).

Currently, there is no way client-code javascript can determine if onscreen keyboard is displayed in fullscren or not because viewport dimensions are not updated.
In comparison, Firefox for Android updates viewport dimensions so the first example is working. Scrolling is broken in Firefox too (second example).
1.0 KB View Download
1.5 KB View Download

Comment 1 by, Mar 22 2017

Labels: -Pri-2 Hotlist-Input-Dev Pri-3
Status: Assigned (was: Unconfirmed)

Comment 2 Deleted

Comment 3 by, Jun 15 2017

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.

Comment 4 by, Feb 6 2018


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
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):

Demonstration of 704070 bug (in fullscreen mode):
correct scrolling down to prompt.png
86.8 KB View Download
keyboard obscuring prompt - no scrolling possible.png
88.0 KB View Download

Comment 5 by, Feb 7 2018

Labels: -Pri-3 Pri-2
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.

Comment 6 by, Apr 9 2018


Comment 7 by, Jun 27 2018

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

Comment 8 by, Jul 4 2018

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?

Comment 9 by, Jul 20 2018

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

Comment 10 by, Jul 30 2018

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

Comment 11 by, Jul 31 2018

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.

Comment 12 by, Aug 3

Did you find the cause?

Comment 13 by, Aug 7

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?

Comment 14 by, Aug 7

Is this any different than:

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

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:

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

Comment 15 by, Aug 7

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.

Comment 16 by, Aug 7

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.

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.

Comment 17 by, Aug 7

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 :-/

Comment 18 by, Aug 7

[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.
35.8 KB View Download

Comment 19 Deleted

Comment 20 by, Aug 8

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

Please check new URL ...

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".

Comment 21 by, Aug 8

Components: -Blink>Input UI>Browser>FullScreen
Assigning to tedchoc@ for triage since this appears to be an Android UI issue.

Comment 22 by, Aug 8

For 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.

Comment 23 by, Aug 8

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

Comment 24 by, Aug 8

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.

Comment 25 by, Aug 8

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.

Comment 26 by, Aug 8

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 , 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 ), 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).

Comment 27 by, Aug 8

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.

Comment 29 by, Aug 8

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.

Comment 30 by, Aug 10

Project Member
The following revision refers to this bug:

commit e7bce2b643b3c32470fcf20a98b7f9e510a2c791
Author: Ted Choc <>
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.


Change-Id: Ieae588fd9a5fc43b700adba399b86fb4e888349d
Commit-Queue: Ted Choc <>
Reviewed-by: Matthew Jones <>
Cr-Commit-Position: refs/heads/master@{#582051}

Comment 31 by, Aug 13

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.
71.3 KB View Download
127 KB View Download

Comment 32 by, Aug 14

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.

Comment 33 by, Aug 17

Project Member
The following revision refers to this bug:

commit f7f385986a69d648d77b0b9f7821e7901df5c90f
Author: Friedrich Horschig <>
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-by: Bernhard Bauer <>
Reviewed-by: Vaclav Brozek <>
Commit-Queue: Friedrich Horschig <>
Cr-Commit-Position: refs/heads/master@{#583987}

Comment 34 by, Aug 21

Confirmed on 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.

Comment 35 by, Aug 21

It does not appear fixed ( ) 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?
83.6 KB View Download

Comment 36 by, Aug 21

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 :/

Comment 37 by, Aug 21

Status: Fixed (was: Assigned)
FWIW, I think the original premise of this bug is addressed in:

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.

Comment 38 by, Aug 21

"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?

Comment 39 by, Aug 21

"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.

Comment 40 by, Aug 21

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 :

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

Comment 41 by, Aug 21

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

Comment 42 by, Aug 21

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.

Comment 43 by, Aug 22

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 ( ).

Comment 44 by, Aug 22

The sites I tested against in this bug:

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.

Comment 45 by, Aug 22

I think it's still broke:

When you click on the textfield ( ), 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.

Comment 46 by, Aug 25


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 :

Please review this change on a non pixel device.
40.5 KB View Download

Comment 47 by, Aug 29

Status: Assigned (was: Fixed)
tedchoc@, can you take another look?

Comment 48 by, Aug 29

Status: Fixed (was: Assigned)
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.

Comment 49 by, Aug 29

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

Comment 50 by, Aug 30

"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 ( ). 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.

Comment 51 by, Aug 31

Status: Assigned (was: Fixed)
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
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
9.9 MB View Download

Comment 52 by, Sep 12

Any movement on this?

Comment 53 by, Sep 12

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.

Comment 54 by, Sep 13

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.)

Comment 55 by, Oct 11

Project Member
The following revision refers to this bug:

commit 1e6e38295e5939b389f667e7a1b19311a11a6296
Author: Friedrich Horschig <>
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
 * 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
Commit-Queue: Friedrich Horschig [CEST] <>
Reviewed-by: Matthew Jones <>
Reviewed-by: Ted Choc <>
Cr-Commit-Position: refs/heads/master@{#598792}

Comment 56 by, Oct 12

Status: Fixed (was: Assigned)
Works for me on trunk. The next Canary should have the fix (version > 71.0.3577).

Comment 57 by, Jan 1

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

I have witnessed this issue on my HTML5 application, The Beast ( ), 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
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).

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.

Comment 58 by, Jan 2

Labels: -Pri-2 Pri-3
Owner: ----
Status: Available (was: Fixed)
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.

Comment 59 by, Jan 2

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 :

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.

Comment 60 Deleted

Comment 61 by, Jan 17

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.

Sign in to add a comment