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

Issue 653016 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Regression: 'Sign in to Chrome' page gets reloaded but nothing is clickable on it after ending webview process.

Reported by rk...@etouch.net, Oct 5 2016

Issue description

Chrome Version: 54.0.2840.50 Revision 4399473cb6f20d12a73c96f668d574005b15f459-refs/branch-heads/2840@{#642}
OS: Windows(7,8,10), Linux

What steps will reproduce the problem?
(1) Launch chrome, navigate to chrome://chrome-signin/?access_point=0&reason=0 and click on 'Create account' link.
(2) Then press Shift+Esc to open task manager and end process of 'Webview:Chrome'
(3) Now click on back navigation arrow and observe.

Actual: 'Sign in to Chrome' page gets reloaded but nothing is clickable on it.

Expected: On 'Sign in to Chrome' page everything should be clickable after reloading page.

This is a regression issue, broken in 'M-45', below is bisect info:

Good Build: 45.0.2431.0
Bad Build: 45.0.2433.0

Narrow Bisect:
https://chromium.googlesource.com/chromium/src/+log/e9ab0758f9148e781ac5fdc5344d432003e2788c..5dc4c114e510b6d6a9d0c5760a8fba17186d0966?pretty=fuller&n=100

Suspecting: r334392

Note: Issue is not seen on Mac OS.
 
Actual_Behaviour.mp4
708 KB View Download
Expected_Behaviour.mp4
537 KB View Download
Labels: -Pri-1 Pri-2
If this truly broke in M45, then it cannot be a Pri-1 regression.

I'll take a look today.
Cc: kenrb@chromium.org
Components: Platform>Apps>BrowserTag
Ok, I've tracked down the problem.

When the navigation in step 3 is performed, a new RenderWidgetHostViewGuest is created, and along with it a new renderer process. But the BrowserPlugin in the embedder is never notified of this (e.g. BrowserPlugin/BrowserPluginGuest consider themselves attached the entire time). BrowserPlugin has set a variable guest_crashed_ = true, and until this is reset to false, chooses to ignore all incoming events (so everything, not just mouse events, will be blocked from propagating from the embedder to the guest). Of course, any event types that have been directly routed (bypassing the embedder) are unaffected.

I'll put up a CL to fix this tomorrow.
Project Member

Comment 3 by bugdroid1@chromium.org, Oct 7 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f73a79830396614b9429612b286dcf6b1df5a356

commit f73a79830396614b9429612b286dcf6b1df5a356
Author: wjmaclean <wjmaclean@chromium.org>
Date: Fri Oct 07 17:40:03 2016

Add IPC to notify BrowserPlugin when RenderProcess is ready.

When a guest renderer crashes, and then is re-created via a navigation,
the BrowserPlugin currently does not get notified, and thus cannot
clear the guest_crashed_ flag. This causes the BrowserPlugin to ignore
incoming input events.

This CL adds an IPC to notify BrowserPlugin when it should clear
guest_crashed_.

BUG= 653016 

Review-Url: https://codereview.chromium.org/2396123002
Cr-Commit-Position: refs/heads/master@{#423897}

[modify] https://crrev.com/f73a79830396614b9429612b286dcf6b1df5a356/content/browser/browser_plugin/browser_plugin_guest.cc
[modify] https://crrev.com/f73a79830396614b9429612b286dcf6b1df5a356/content/common/browser_plugin/browser_plugin_messages.h
[modify] https://crrev.com/f73a79830396614b9429612b286dcf6b1df5a356/content/renderer/browser_plugin/browser_plugin.cc
[modify] https://crrev.com/f73a79830396614b9429612b286dcf6b1df5a356/content/renderer/browser_plugin/browser_plugin.h

Status: Fixed (was: Assigned)
This should now be fixed in ToT. Please re-open if issue recurs.

Sign in to add a comment