Created attachment 380434 [details] iPhone 5 screenshot An app is using WKWebView for main screen. Since the end of August, users are experiencing a random bug where after launching or after returning from background, they see no content (just a dark gray area) below certain position on the page (when scrolling). This position is not constant - sometimes it's right at the top of the page (still below the first screen, on iPhone X it is around 444 points below the bottom of the screen [aka at around 1256 points from top of the page]), other times it is further down the page (in cases when it happens after returning from background). When the bug happens, scrolling is available up and down (works correctly). But no JavaScript seems to get executed: no click/touch events are fired and remote debugging (via Safari Preview + USB cable) is partially broken - connection is established (Sources are populated), however console is non-functional. I've gotten reports that this resolves itself after about 30 seconds, but typically users just restart the app and don't wait for it to fix itself. I've attached a screenshot to illustrate what the user sees when it happens. Possibly related to bug 193665. However, I'd guess its the JS engine getting stuck and taking the renderer/compositor with it. There is no crash so no crash log, but I'm open to suggestions about how I can gather more data on this.
Is this app available on the App Store?
Yes. The appID is H4V3P999U5.com.gamingtribe.ios
Have you managed to reproduce this bug yourselves?
Created attachment 380571 [details] Working system log at app startup (filtered by WebKit)
Created attachment 380573 [details] Broken system log at app startup (filtered by WebKit)
Yes. I have more details too, including some logs. Sometimes (I was able to do it twice) returning to home screen and then focusing the app fixes it - content in gray area instantly appears. Additionally the content on the page may be interactive, but its rare, typically nothing is responsive while the problem manifests itself. I've attached two log files (system logs filtered by WebKit). One working and one when it broke.
We've discovered some interesting behavior. Relevant intro: the app features two WKWebViews, one for interacting with the native APIs and another for loading web content. The two then interact with webkit.messageHandlers. What we've noticed is that when the app (topmost visible WKWebView) is in a broken state, opening the Safari Preview, then the Develop dropdown menu, expanding XYZ's iPhone submenu and merely mousing-over the "localhost" entry (internal WKWebView, not visible on the screen) restores the rendering on the topmost WKWebView that contains remote content. This is consistent and works every time. Another interesting thing is that removing all webkit.messageHandlers calls from the native side seems to have resolved the issue, or at least it's not as easily reproduced any more.
More details. We can't reproduce this on iPad (with iPad OS). Earliest reports are from 12.4.1 (however 12.4 is possible). Reproducible all the way through iOS 13.2 Beta 1. As mentioned in the previous comment, removing all evaluateJavaScript calls to WKWebView object stops the bug from being easily reproduced (we weren't able to reproduce it so far). Having at least one evaluateJavaScript call makes it appear but at a lower frequency than making all of the evaluateJavaScript calls that we normally make during loading. Furthermore, when the bug occurs, JSContexts that are pending are not executed (when bug happens during loading, that means no JSContext is executed at all) until the freeze is resolved. The "unfreeze" happens either via an undetermined (likely random) timeout, sometimes by minimizing and restoring the app and everytime by mousing over the non-frozen WKWebView OR JSContext entry in Develop dropdown menu of Safari Preview. To reproduce the bug again we no longer restart the app, we just issue location.reload() to the topmost WKWebView. The "success" rate of reproducing it is still about 20%. It can happen twice in a row or be okay for 10 consecutive attempts. We tried doing 5 times the regular evaluateJavaScript calls during loading (125 calls in total) and it doesn't seem to affect the rate of occurrence. Please let me know what's the best way to capture the state of the app when it happens, so I can supply more relevant logs.
Can you create a simple small test app that shows the bug?
Yes, we can do that. But it will require Apache Cordova CLI to build the app. Would that be a problem?
Do you have access to a dev environment with cordova-cli installed? The issue seems to become more frequent with every minor releases of iOS 13 that comes out.
No(In reply to teodor.atroshenko from comment #11) > Do you have access to a dev environment with cordova-cli installed? I do not.
Is the grey colour the same as the background colour for the body of the page? Can't tell conclusively from your screen shot, but it appears to be the same as the bar above so I'm guessing it might be. I found this report because we have rare rendering bug around scrollable content inside of a flexbox container that itself is using positoin: fixed. The effect of the bug is that large areas of content are just rendered with the page background-color, and there's a sort of window that can be scrolled up and down to reveal content. I can't tell from the descriptions here if this is the same or a related issue, so I'm attaching a short gif to get your thoughts. We do use some messaging, but that's not active here (or shouldn't be) but UI elements do not respond. Haven't waited to see if it fixes itself because I'd not read that until now.
Created attachment 391025 [details] GIF showing a rendering issue that may or may not be the same This is using WKWebView in an objective-c based app in iOS 13.x
(In reply to lacey from comment #13) > Is the grey colour the same as the background colour for the body of the > page? <body>'s background color is white, but there are other DOM elements, opaque background of WKWebView itself and status bar colors that match exactly the color of the "blank" area that is rendered on the page. I do not have a screen capture recording of this, but the behavior is very similar to your GIF with a couple of differences: 1. When the rendering fails "above" the current content, the toolbar ("position: fixed; top: 0") remains displayed. So the "broken" area of the page does not cover it. However, in the GIF it seems like the content at the top of the page that gets covered is not part of WKWebView, so this point may not be relevant to the issue. 2. We are able to scroll the page (<body>) and in the GIF it seems like undesired scrolling is happening - there is no content overflowing the screen. However, in our case there is always content overflowing, so there is always content "below" to see, so you can always scroll the page in our case. 3. The "broken" area is not affecting the actual content of the page in your GIF. In our case, all content of <body> below or above certain scroll position would fail to render. In your case the content is still being drawn and there is something else covering it. This may be due to some native scrolling happening somewhere. You can try running Safari Preview on Mac, connecting the iPhone (with Web Inspector enabled in Settings app for Safari), and then mousing-over the WKWebView entry on Mac's Safari in Develop -> "Your iPhone's name" -> WKWebView page URL. When you mouse over, it should highlight the WKWebView on your iPhone and you'll be able to see its bounds. Then try scrolling and see if the bounds remain the same or if they begin to change.