Video demonstrating the problem: https://bug1416849.bmoattachments.org/attachment.cgi?id=8927916 The page is not fully rendered and is cut off towards the bottom of the page. The content size of the page is correct and the cut off area is whitespace. The cut off point appears consistent when consecutive pages are loaded, about 50% longer than the viewport y. Seems to correlate with memory pressure, but once pressure is relieved, the WKWebView will continue to render pages cutoff. Reproducibility: Difficult to repro. Firefox iOS has many reports of this, primarily on iPad (various models), and it is highly reproducible given a long enough browsing session for me. (Firefox iOS X-ref https://bugzilla.mozilla.org/show_bug.cgi?id=1416849)
<rdar://problem/35657388>
See also https://bugs.webkit.org/show_bug.cgi?id=169618#c5
The key to understanding this will be to get reproducible steps. Have you made any progress there?
Also, if we test with the current Firefox app, is the bug going to be hidden by workarounds?
The last version of Firefox, 10.3, has no workarounds in place. We can also make special builds, put you on TestFlight or send a debug Enterprise build. If I am correct, the workaround that Chrome put in place has not yet shipped. But someone from the Chrome team can confirm that. Can you give us some guidance about how to best debug this? Console.app is like a thunderstorm of events. Is there something specific that we should be filtering on? I will also ask the team to post whatever we have found / explored to this bug.
I would look for memory warnings and web process crashing in the log. It's possible that this is a bad state that occurs after the web process crashes and comes back.
The chromium team has also opened a radar rdar://35063950 they might have an STR. in Firefox iOS, iPad (the older the better) running ios 11.1.2. 1) open anywhere from 10-20 tabs on content heavy web pages. Sites like nytimes/theguardian etc work well 2). Add more apps into memory. Opening heavy apps like games helps build memory pressure quickly. 2). switch between these tabs until you start seeing reloads happening (WKWebView was killed and webViewWebContentProcessDidTerminate called). 3) try switching between tabs and scrolling. After a few mins one of the tabs will fail to render pass what is displayed on the screen. I've checked the innerHTML of said page and the HTML is correct but still fails to render. Sorry for such an imprecise STR
The Chrome radar explicitly says "after a crash" (or jetsam/eviction). Is that the Firefox experience too?
It's possible that https://trac.webkit.org/changeset/221906/webkit fixed some or all of the symptoms here.
No crashes for us. There is a movie attached to our bug that shows this in action: https://bug1416849.bmoattachments.org/attachment.cgi?id=8927916
(In reply to Simon Fraser (smfr) from comment #6) > I would look for memory warnings and web process crashing in the log. It's > possible that this is a bad state that occurs after the web process crashes > and comes back. Are webkit process crashes reported as regular crashes? Do they dump crash reports on the device? If not, is there something we can configure to enable that?
As briefly mentioned on the Mozilla bug: I see this behavior in Firefox v9.3 on my small iPad Pro running iOS 11.1, and I also see it on my phone in a recent Firefox master build, again running a new iOS. I see this when the browser has been open and loading lots of pages (often relatively large web forum pages) for a while. A force-quit and relaunch fixes it. My iPad feels relatively sluggish and memory-constrained since upgrading to iOS 11, so I wouldn't be surprised if this were memory-related. I think the only common factor is iOS 11 (or even 11.1); my iPad has been running Firefox 9.3 for ages, and hadn’t displayed a problem until recently. I also never saw an issue on iOS 10. My approximate STR: - Get an iPad Pro. - Install Firefox. - Sync your history (I do; might be relevant in increasing memory footprint). - Open a few dozen tabs on large web forums and other similarly non-trivial pages — having the pages be more than 1.5 screens high seems necessary to see an issue! - Browse and scroll, browse and scroll, open new tabs, browse and scroll…
just to clarify what Stefan meant. We are seeing `webViewWebContentProcessDidTerminate` calls (webview crashing) when this bug happens. But not actual full app crashes.
Ah, by "crash" I did mean web process crash (i.e. webViewWebContentProcessDidTerminate). So there's a good chance that this is fixed.
Thats awesome! thanks for digging into this for us! When can we expect this to land in iOS?
I can't say, but will note here when a testable build is available.
r21906 is in the released 11.1, so you have that fix already. This actually sounds more like the problem fixed in r223082.
Created attachment 333500 [details] Proof-of-concept iOS app The code in this attachment can also be found at: https://github.com/justindarc/BrokenWebViews Steps to reproduce: 1. Build "BrokenWebViews" app via Xcode 9 and run on current-gen iPad 9.7" 2. Tap each "tab" at the bottom of the screen one-by-one allowing the page to load it's content before continuing to the next 3. After the 8th "tab" has loaded, start tapping the tabs in reverse-order one-by-one until you reach the 1st "tab" again 4. Observe a blank white WKWebView in the 1st "tab" 5. Tap "Reload" button and try to scroll after page reloads 6. Observe that WKWebView cannot render anything beyond the initial viewport Also, when this problem exhibits itself, observe the following messages logged to the console: 2018-02-09 13:44:08.547900-0500 BrokenWebViews[2847:1337656] [ProcessSuspension] 0x1c4275f40 - ProcessAssertion() Unable to acquire assertion for process with PID 0 2018-02-09 13:44:08.635358-0500 BrokenWebViews[2847:1337656] [ProcessSuspension] 0x1c0662240 - ProcessAssertion() Unable to acquire assertion for process with PID 0 2018-02-09 13:44:35.420269-0500 BrokenWebViews[2847:1337566] Could not signal service com.apple.WebKit.WebContent: 113: Could not find specified service 2018-02-09 13:44:37.285543-0500 BrokenWebViews[2847:1337566] Could not signal service com.apple.WebKit.WebContent: 113: Could not find specified service
To clarify, in Comment 18, this behavior was observed on iOS 11.1.2 and 11.2.5. Also, if you're having trouble reproducing, try scrolling to the bottom of the page before tapping on the next "tab".
Does this reproduce in the iOS 11.3 seed?
TLDR I have not been able to reproduce a partially rendered page yet in 11.3b2. Here are some test results on an iPad Pro 9.7" with 11.3b2: The original STR still works, but I have to cycle through the open tabs a bit more usually. But eventually a blank tab appears and I see the following in the console: 2018-02-09 14:46:37.928885-0500 BrokenWebViews[720:105836] [ProcessSuspension] 0x1c0471380 - ProcessAssertion() Unable to acquire assertion for process with PID 734 2018-02-09 14:46:44.829379-0500 BrokenWebViews[720:105835] [ProcessSuspension] 0x1c046a180 - ProcessAssertion() Unable to acquire assertion for process with PID 738 2018-02-09 14:47:00.044491-0500 BrokenWebViews[720:105722] Status bar could not find cached time string image. Rendering in-process. 2018-02-09 14:47:07.930312-0500 BrokenWebViews[720:105722] Could not signal service com.apple.WebKit.WebContent: 113: Could not find specified service 2018-02-09 14:47:14.828643-0500 BrokenWebViews[720:105722] Could not signal service com.apple.WebKit.WebContent: 113: Could not find specified service But now when I hit reload, the page reloads, and it is fully rendered. One additional thing I tried is this: I scroll every tab down a little bit. With the same STR, when I reload a blank page, the page reloads and also restores its scroll position.
We are getting another 11.3b2 device ready to have more than one data point.
I'm going to call this fixed. Please file a new bug on the ProcessAssertion issue.
comment #22 follow-up: second confirmation on 11.3b2 (on ipad air v1) that this bug appears to be fixed.