New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 739652 link

Starred by 3 users
Status: Assigned
Owner:
wjmaclean@chromium.org
Cc:
kenrb@chromium.org
rbasuvula@chromium.org
█ msrchandra@chromium.org
█ ranjitkan@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Regression: Unwanted page of killed Webview process is seen while reloading page in 'Browser sample' app.

Reported by db...@etouch.net, Jul 6 2017 
Chrome Version: 61.0.3150.0 Revision e32c608bfaee28eb9bd478073a2f222fb6c28133-refs/heads/master@{#484424}(32/64 bit)
OS: Windows (7,8,8.1,10),Linux (14.04 LTS),Mac OS X(10.10.5, 10.11.4)

Pre-condition: Add 'Browser sample' extension from 'Load Unpacked extension' in chrome://extension.

What steps will reproduce the problem?
(1) Launch chrome, Launch 'Browser sample' extension then click on Simulate crash icon near omnibox.
(2) Then click on Reload icon and observe on page while reloading.

Actual: Unwanted page of killed Webview process is seen while reloading page.

Expected: Loading of page should be proper.

This is a regression issue, broken in 'M-59', will soon update the other info:

Good Build: 58.0.3029.0
Bad Build: 59.0.3030.0
Actual_Result.mp4
589 KB View Download
Expected_result.mp4
352 KB View Download

Comment 1 by db...@etouch.net, Jul 6 2017

Labels: hasbisect
Owner: kenrb@chromium.org
Status: Assigned (was: Unconfirmed)
Narrow Bisect:
https://chromium.googlesource.com/chromium/src/+log/45bc57b54c6a1e20ed41254327a06de44ea7bb1d..640a3ee813640e1b3f958933316cc15f4b88b1be?pretty=fuller&n=100

Suspecting: r454578

@kenrb: Please help me to reassign this issue, if your change is not cause for it.

Comment 2 by kenrb@chromium.org, Jul 6 2017

Cc: -nyerramilli@chromium.org kenrb@chromium.org
Labels: -Pri-1 Pri-2
Owner: wjmaclean@chromium.org
I think the behavior here is that the browser process is rejecting the white background paints from the new <webview> (which hasn't navigated yet), and so is painting the crashed webview graphic.

This by itself is correct behavior. I don't think this is a significant regression, but if we want to fix it, then we could do something like attach a white background in the embedder process to the <webview> layer after it starts loading.
►

Sign in to add a comment