Webview white-pages on large html page with many styles
Reported by
david...@amazon.com,
Aug 19 2016
|
|||||||||||||||||||||
Issue descriptionExample URL: see attached test.html Steps to reproduce the problem: (1) Launch app with test.html (2) Scroll down as far as you'd like and see white screen rendered (3) Press home button and put app in background (4) Resume app and try to refresh the page What is the expected behavior? Page should begin to refresh What went wrong? Device name: Samsung S5, Android version: 6.0.1 WebView version (from system settings -> Apps -> Android System WebView): Specifically 51.0.2704.81 Application: HTML5test WebView Application version: latest URLs (if applicable): See test.html. This reproduces on HTMLs with many different styles. Expected result: Page should begin to refresh Actual result: Page takes a very long time to start the reload/new navigation as the page will be white screen / stuck on previous screen. My use case is testing on a very-large HTML page with many styles on it. I notice that the InProcRendererThread will spend too much time in Document::updateStyle() after we put the webview in background and try to resume. When we want to start a new navigation or refresh the page, then the InProcRendererThread seems to be stuck in Document::updateStyle() and will not accept new message to start a new navigation until much later. See trace "trace_webview51-updateStyle-stuck.json" for this behavior and I see the following: 1) At 9,842 ms we see event LoadURLWithParams indicating the new navigation started when we refreshed the page (Step 4 of repro) 2) InProcRendererThread Document::updateStyle starts at 6,021 ms and lasts ~26 ms. 3) In CrBrowserMain we don't see callback for WebViewContentsClientAdapter.onPageStarted until 34ms, despite navigation starts loading at 9 ms. Is this behavior expected? Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Yes On a custom webview version built off of v41, this issue does not reproduce. The content renders fast while scrolling on this version. Does this work in other browsers? N/A Chrome version: 51.0.2704.81 Channel: n/a OS Version: 6.0.1 Flash Version:
,
Aug 24 2016
Test team - the attached test file (note this file was in the original report, I've extracted it from the zip) is ~5.5MB and takes Chrome ~5 secs to parse and become responsive on my Mac with Chrome 54.0.2837.0 (ie the 'X' turn back into 'reload', and the spinner on the tab stopping). It's much worse if you start to scroll past the initially rendered text. In Firefox it's almost instant. Can you please bisect to see if this is a regression?
,
Aug 26 2016
For large files, we parse html in chucks with some maximum amount of work before yielding to the scheduler which allows style recalc and layout to happen very often. That is basically the difference in load time to Gecko which allows for everything to parse before calculating style and laying out. I have commented on this issue before, but I'm not able to find that crbug issue now.
,
Aug 26 2016
,
Aug 26 2016
,
Sep 9 2016
,
Oct 26 2016
It sounds to me like the better behavior would be to not allow a refresh until the whole page is loaded. Or would you expect a refresh to cancel the current page load and refresh immediately? I don't think there's anything we can do to render the page any faster.
,
Dec 27 2016
Removing,'Needs-Bisect' label, since I don't think anything needs to be done from Webview TE side. I have checked with ntfschr@ too. Thanks!
,
May 10 2017
Not sure what steps we can take here, but I'll open this up to any WebView team member to take a look at.
,
May 11 2017
re: comment 2, I can reproduce the ~5s time on my Linux desktop with Chrome Linux 58.0.3029.96 (Official Build) (64-bit) but I don't see any interesting rendering or responsiveness issues. So this is fixed or doesn't affect Linux. It is probably premature to say this is the HTML parser. It might be related but there's a lot of other systems which could be equally relevant. I'm going to mark this untriaged, we should confirm if this is still an issue. I think the idea of bisecting it (Comment 2) is a good one.
,
May 11 2017
My comment #3 was about why it takes ~5s in Chrome, while almost instant in Firefox. Not about responsiveness.
,
May 11 2017
,
Jul 10 2017
Just loading the page with no user interaction is working as expected. Blink parses and layout in chunks, which takes roughly 500ms each on my nexus 5. The problem is if user flings down and keeps sending gestures. Each time there is a touch down, webview requests a hit test, and this appears to be the super slow thing that can potentially take seconds. Webview can't really remove that hit test because it's for implementing some legacy APIs that came from the day when the original webview ran the webkit main thread on the UI thread. But there's a few things that's probably worth investigating. * why are those hit tests taking so long? Can anything be done to make it faster? I see each hit test is doing a layout, maybe that's the expensive part? * It looks like all these hit testing is essentially starving parsing. Webview's hit test happens in an IPC. Is there any way to "deprioritize" that that in terms of scheduling? Or maybe browser side should wait for an ack and not allow hit test requests to queue up. There is not much point bisecting. Same behavior on 51 and 60.
,
Jul 18 2017
I'm looking into all these HitTesting bugs.
,
May 29 2018
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by junov@chromium.org
, Aug 22 2016