Apps <webview> resizing is laggy |
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:49.0) Gecko/20100101 Firefox/49.0 Steps to reproduce the problem: When resizing a window containing a <webview> spanning e.g. 100% width/height, there is a noticeable delay until the <webview> resizes. See example here: https://gist.github.com/anonymous/15d8947ddc7ad881947275d4d26e40bd Or just run: $ git clone https://gist.github.com/15d8947ddc7ad881947275d4d26e40bd.git webview-resize-slow $ cd webview-resize-slow $ /path/to/chrome --load-and-launch-app=$PWD What is the expected behavior? With the linked example, the red background of the page should ideally never be visible when resizing. The <webview> contents should always span the window width/height. What went wrong? The delayed <webview> resize causes the red background of he page to be visible. WebStore page: https://gist.github.com/15d8947ddc7ad881947275d4d26e40bd.git Did this work before? No Chrome version: 52.0.2743.116 Channel: stable OS Version: OS X 10.11 Flash Version:
,
Aug 23 2016
Yes, I can reproduce this on a new profile and also with libchromiumcontent based applications that exercise the same code path (e.g. <webview> in Electron). Can someone with the appropriate bits move this to Platform>Apps>BrowserTag and CC paulmeyer@chromium and lazyboy@chromium?
,
Aug 23 2016
The screencast doesn't show the issue. Please try increasing the size of the window quickly and you will see the red background.
,
Aug 31 2016
Thank you for providing more feedback. Adding requester "tkonchada@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 12 2016
,
Nov 6 2016
,
Nov 6 2016
From emailing with the submitter it sounds like this affects other desktop applications embedding Chromium such as Slack and Brave. This seems quite serious so please either provide an update on progress or raise to P1 and set a release target as appropriate. Thanks.
,
Nov 7 2016
<webview> runs out of process, so the asynchronous nature is by design. I think the mitigation would be to not paint until both the embedder and the webview has finished drawing a frame, but it may not be ideal. Assigning to wjmaclean@ who is already owning a similar issue on out of process I frames.
,
Mar 13 2017
Cleaning up "Needs-Review" label as we are not using this label for triage anymore. Ref bug for this cleanup 684919 |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by tkonch...@chromium.org
, Aug 23 2016Labels: Needs-Feedback
15.3 MB
15.3 MB Download