Bug report gathered just now when the behavior started again:
https://drive.google.com/drive/folders/1CB2VRQmIQqctqejauCgnFk5z-RAm64m4?usp=sharing

Google internal only.

I actually noticed this too. I think this is a browser UI issue and not relating to login state but I'm not sure.

My first thought was https://chromiumdash.appspot.com/commit/6f4d1915dbc5f2bb56e29e0a3a1dc13407c884f5 but that was M66 which was a while ago

Tentatively assigning to Peter but cc'ing some related owners for webapps/twa in case anything comes to mind

Going to tentatively flag M-66 cause I can't really dismiss that CL as a candidate at the moment. 

kbr: is it possible we've been seeing this since March 7? I feel like that's too long ago but not sure

Another Q: do you notice any association between this and puhs notification? I wonder if chrome is started for notificatoin and then we show UI whether this may have an impact (just testing theories)

It is possible it started happening that early in March. I'm really sorry I didn't file this earlier, but don't remember when I first saw it.

Thinking about it more, it can't have lost my login credentials, because otherwise it would be unable to display any tweets at all. (I tried this in an incognito Chrome Dev tab after filing the bug, and Twitter just requests you to log in.)

https://chromiumdash.appspot.com/commit/6f4d1915dbc5f2bb56e29e0a3a1dc13407c884f5 sounds plausible. I don't know the default rendering state of a Chrome Custom Tab but note the generic header when the PWA gets into this state, rather than the regular profile picture.

Is there any more information I can gather when this happens the next time? Should I connect DevTools to the Chrome instance hosting Twitter Lite and gather anything?

This is also happening for me on both Twitter Lite and another home-screen installed app. Version 67.0.3381.2. No UI events work, can't click on any links.

pkotwicz@ any update here? M66 release is nearing.

No updates. I have not yet been able to reproduce this bug

Rick mentioned seeing this too but couldn't exactly pin repro steps. He mentioend seeing it on Beta which would suggest this is M66 (or site-specific behaviour). I haven't seen this in the last few days.

Peter: wondering if this at all could be if a navigation happens while it's in the background?

I think I've seen this only once in the past few days, on Dev Channel (M67). The incidence definitely seems lower than when I filed the bug.

CCing tedchoc@ in case he knows of a CL which affected the browser control visibility logic - FullscreenManager#setPositionsForTab() and friends

Yaron: The logic for whether the minimal UI is shown is really simple. If the navigation is for the same origin and the origin is secure the minimal UI won't show

- Tab#handleRendererUnresponsive() looks interesting
- The logic for computing the browser control offset is super complicated
- I have a vague memory of the browser controls being initially visible in the WebappActivity regardless the display mode

kbr@: Do you remember whether when you tapped the app icon and the WebAPK with the bad state was brought to the foreground whether you saw the splash screen in between the time that you tapped the app icon and the bad state?

There has been some changes around fullscreen visibility for tab modal dialogs (i.e. javascript dialogs), but those aren't enabled for anything but tabbed mode.

+huayinz

handleRendererUnresponsive now goes through the tab browser offset helper, but that calls ChromeFullscreenManager#setPositionsForTabToNonFullscreen.

Tangent for TabBrowserControlsOffsetHelper, but we should probably check Tab#canShowBrowserControls before forcing the browser to override the renderer value (I think this happened much after 66, so I wouldn't expect this to be the cause on beta).

Maybe just add a timer for renderer unresponsive and make sure that isn't the cause.  If it is, we should just ensure that Tab#canShowBrowserControls is false for webapks at that time.

pkotwicz@: I recall that the splash screen did *not* come up in this state – it didn't look like the Twitter Lite PWA restarted, but rather just navigated directly to its last state, only with the wrong tab decoration.

However, it's been a couple of days since I've seen this behavior (on Dev Channel, at least), so maybe we should downgrade this until it's more reproducible. There is a more serious regression in notifications with this PWA:  Issue 830211 .

If Tab#handleRendererUnresponsive() were to call TabBrowserControlsOffsetHelper#showAndroidControls(animate=true) instead of
TabBrowserControlsOffsetHelper#showAndroidControls(animate=false) the browser controls would show

The good news is that this tells us the likely state of Java vs native in the error case. This is a screenshot as a result of making the change in Tab#handleRendererUnresponsive(). Notice the position of the "Tweet" button

Deleted: twitter_bad.png 770 KB

	twitter_bad.png 770 KB View Download

Any more progress here? We are planning to cut the RC in few days.

There's only one place that calls showAndroidControls(animate=true): Tab.onTabModalDialogStateChanged

Or is that valid just not under the circumstances in which it's called there?

I'm not sure this represents the bug I saw though because I believe the content was hidden under the minimal UI.

cmasso: we aren't currently able to repro the situation and it's possible that it was a site error. I guess we'll unblock the train but keep digging

Yaron: showAndroidControls(animate=true) is not to blame. Tab modal dialog are only shown by ChromeTabbedActivity.

I am trying to understand the bug that I can repro in order to figure out the bug that I cannot repro.

The toolbar is moved as a result of ChromeFullscreenManager#setPositionsForTab()
The web contents are repositioned vertically as a result of CompositorView#onCompositorLayout() which is called from SingleThreadProxy::DoBeginMainFrame()

I need to do more investigation into what makes things work most of the time. We should likely call CompositorViewHolder#requestRender() unconditionally from CompositorViewHolder#onControlsOffsetChanged()

CCing fsamuel@ who knows a lot about how the browser controls are repositioned on Android

Assigning the bug to fsamuel@. There has been a ton of churn in the viz code. The viz code is responsible for determining when a composite for the browser compositor is requested. The WebContents are repositioned vertically as a result of browser compositor composites - CompositorImpl::UpdateLayerTreeHost()

This was working reliably for a while but regressed again in Chrome Dev Channel about two days ago (so around June 25). Right now Chrome Dev is:

69.0.3464.0 (Official Build) dev (32-bit)

Most of the time the Twitter Lite PWA renders correctly but in some situations (which I haven't been able to reliably reproduce) it gets into the state originally reported. Dismissing the PWA from the app screen overview and reopening it makes it work correctly again.

Can anyone else reliably reproduce this? The Twitter Lite PWA is one of my main uses of Chrome on Android and it's disappointing that it doesn't work reliably.

Haven't found a reliable repro but +1 have been seeing this again recently.

Thanks for the report! Fady, ptal

jeffcarp: what channel and version of chrome are you using? 

From server logs the twitter pwa may also have updated recently so perhaps we have an issue with or during updates. If we see this on non-dev channel this might be an explanation

I'm on dev channel, 69.0.3464.0

FYI I saw this again earlier today when reopening the Twitter Lite PWA from the homescreen icon after it had previously been opened. I'm pretty sure it's not related to updates of the PWA.

Thanks - that's helpful. SO we need to look at binary changes

I'm unable to repro this locally.

I haven't seen this in the past couple of weeks.

I'm not sure if this is still a bug and I'm not actively looking at it so I'm unassigning myself.

Haven't seen this in a while so closing as WontFix.

We still think there's a subtle race here that's getting triggered at times. Peter's chasing  issue 861618  and I suspect fixing it will fix this too

kbr: at long last  issue 861618  was root-caused and fixed. Please reopen if you see this again after 73.0.3637.0 but hopefully it's all good now :)

Thank you Yaron!