You are probably looking for a change made after 580944 (known good), but no later than 580945 (first known bad).

CHANGE-LOG URL:

The script might not always return single CL as suspect as some perf builds might get missing due to failure.

https://chromium.googlesource.com/chromium/src/+log/5e5bab0a2c26532215cb0b2f6a39ed64591c5d70..5527323788b6dc575acbd601778350ca0b221699

Suspect: https://chromium.googlesource.com/chromium/src/+/5527323788b6dc575acbd601778350ca0b221699

@lukasza: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thank You..!!

Just to update : Unable to reproduce the issue on CORP and NON-CORP systems on Canary #70.0.3515.0 and Dev RC #70.0.3514.0 on Windows and 70.0.3514.2 on Mac builds.

@Vineetha: Could you please try one more time and let us know the observations. Please attach the GPU details.

Thank You!

I see a delay in loading the page in canary- 70.0.3515.0, but not "page unresponsive".

https://chromium.googlesource.com/chromium/src/+/5527323788b6dc575acbd601778350ca0b221699  seems to be an intentional change. lukasza@ could you please confirm. 

Tagging with an RB label for tracking purpose.

Thanks for the report and for the video of the repro.

One thing I see in the video is that the navigation spinner stops spinning a good few seconds before the hung renderer dialog pops up.  If one trusts the spinner, then it means that all the navigations have completed/committed and *then* the commit timer fired.  This is unexpected and most likely indicates a bug has slipped alongside r580945.  OTOH, nailing and fixing the bug might be difficult without repro steps / without consistent repro...  Maybe |commit_timeout_timer_| should be stopped in more places (e.g. in the destructor of the NavigationHandleImpl)?

I am getting a consistent (5 out of 5 attempts) repro when launching ToT Chrome with a *fresh* profile like so: out/rel/chrome --user-data-dir=$HOME/.chrome-youtube-hang5 https://www.youtube.com

So far I was not able to repro when reusing the profile.

Given that I can repro at will, let me revert the culprit CL and try again after I've understood and addressed the problem caused by the repro steps.

Is this bug same as - Issue 871730, lukasza@ please  confirm.

This bug is responsible for the spike seen in issue 871730.  I can't say for sure if it accounts for the entirety of the spike.  But, the revert (in CQ in https://chromium-review.googlesource.com/c/chromium/src/+/1165902) should take care of the entirety of the spike.

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

commit 3d62b3b2040506828111f59bad9f03a42c01018a
Author: Łukasz Anforowicz <lukasza@chromium.org>
Date: Wed Aug 08 00:40:15 2018

Revert "Show "hung renderer dialog" after a navigation commit timeout (10s)."

This reverts commit 5527323788b6dc575acbd601778350ca0b221699.

Reason for revert: Caused  https://crbug.com/871704  and https://crbug.com/871730

Original change's description:
> Show "hung renderer dialog" after a navigation commit timeout (10s).
>
> In addition to adding a content_browsertest, I've also manually tested
> the changes using steps from https://crbug.com/810633#c14.
>
> Note that after this CL a "hang renderer dialog" will appear if a
> navigation cannot commit because it tries to reuse a hung renderer.
> This is definitely an improvement.  But also note that after using the
> dialog to kill the renderer, the navigation spinner will keep spinning -
> there is additional work needed to fix this.
>
> Bug: 848821
> Change-Id: I9d6801dbd8b2532f2427509c938db5556a4fb133
> Reviewed-on: https://chromium-review.googlesource.com/1089797
> Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
> Reviewed-by: Avi Drissman <avi@chromium.org>
> Reviewed-by: Charlie Reis <creis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#580945}

TBR=avi@chromium.org,creis@chromium.org,lukasza@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: 848821, 871730,  871704 
Change-Id: I2dee152ba283fbba332437d5c470205604ea4691
Reviewed-on: https://chromium-review.googlesource.com/1165902
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#581414}
[modify] https://crrev.com/3d62b3b2040506828111f59bad9f03a42c01018a/chrome/browser/ui/hung_renderer/hung_renderer_core.cc
[modify] https://crrev.com/3d62b3b2040506828111f59bad9f03a42c01018a/content/browser/frame_host/navigation_handle_impl.cc
[modify] https://crrev.com/3d62b3b2040506828111f59bad9f03a42c01018a/content/browser/frame_host/navigation_handle_impl.h
[modify] https://crrev.com/3d62b3b2040506828111f59bad9f03a42c01018a/content/browser/renderer_host/render_widget_host_impl.cc
[modify] https://crrev.com/3d62b3b2040506828111f59bad9f03a42c01018a/content/browser/renderer_host/render_widget_host_impl.h
[modify] https://crrev.com/3d62b3b2040506828111f59bad9f03a42c01018a/content/browser/site_per_process_browsertest.cc

 Issue 872547  has been merged into this issue.

Update :
Rechecked the above issue on Windows(7,8,8.1,10) OS with latest Canary Chrome version #70.0.3517.0 and the issue is fixed. Unable to check the issue on Mac since latest Canary for Mac is not yet available .Will update Mac behavior once build is available.

Kindly refer the attached screen cast.

Deleted: CanaryBehaviour.mp4 1.9 MB

	CanaryBehaviour.mp4 1.9 MB View Download

Internal follow-up bug in YouTube: b/110149556

Follow-up bug:  issue 872803  (XFO/deny leaks NavigationRequest/Handle)

Update :
Rechecked the above issue on Windows(7,8,8.1,10) and Mac(10.12.6,10.13.1,10.13.6,10.14)OS with latest Canary Chrome version #70.0.3518.0 and the issue is fixed.

Kindly refer the attached screen cast.

Deleted: FixedVideo2.mov 13.1 MB

	FixedVideo2.mov 13.1 MB View Download

This has been fixed by the CL in #c12.