Works fine in Chrome Stable.
Link to video: https://drive.google.com/a/google.com/file/d/0B-xmXLQhjeKuWDdFMnZaRkF6c3c/view?usp=sharing

+spqchan for any recent omnibox changes, shrike FYI.

Looks like a regression, marking as such. 

Tested on Mac 10.11.6 using latest chrome channels  canary M56 #56.0.2914.0 , Dev M56
#56.0.2906.0 , Beta M55 #55.0.2883.35 and stable M54 #54.0.2840.87 and issue is not reproduced.

Attached screencast for reference.

Note : Issue is reproduced on M56 #56.0.2912.0 and not on any other latest chrome channels.

Please let us know , if we need to provide bisect.

Thanks !

Deleted: 663064.mp4 2.8 MB

	663064.mp4 2.8 MB View Download

[Mac Triage] Also, can't reproduce on 56.0.2914.0. A bisect may still be useful to know what caused the issue though.

As per comment #7 , Using the per-revision bisect providing the bisect results,
Good Build : 56.0.2908.0 (Revision: 429486)
Bad Build: 56.0.2910.0 (Revision: 430103)

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

CHANGELOG 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/53acce88363fb6a9ed54e991d17b203cfdf6326d..45e3b18b7312c37abd86c300d045b5e43ea1ec72

From the CL above, assigning the issue to the concern owner 

@agrieve - 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.

Review-Url: https://codereview.chromium.org/2479463004

Note : Issue is fixed in M56 #56.0.2914.3 

Thanks!

#8 is for android and java so it's hardly related to the issue.

Here's the snapshot-bisect that makes me suspect throttling of backgrounded tabs, also based on the fact the repro steps specify youtube playing in a background tab.

Broken in 56.0.2910.0:
	429853 (good) - 429862 (bad)
	Changelog: https://chromium.googlesource.com/chromium/src/+log/4dc6d5c3..cdb3463e?pretty=fuller
	Suspecting: r429861 "Teach scheduler about audio state"

Fixed in 56.0.2913.0:
	430348 (bad) - 430357 (good)
	Changelog: https://chromium.googlesource.com/chromium/src/+log/52d00fd5..78bd9c63?pretty=fuller
	Suspecting: r430353 "Do not use audio signal in policy for renderer scheduler"

agrieve@, Gentle Ping!

Could you please take a look

#10, the problem wasn't caused by agrieve's change because the bisect in #8 is wrong. See #9.

Thanks. Removing myself as owner.

Let's try a bisect once more.

Tried Reverse Bisect using per-revision bisect ,
Good Build: 56.0.2913.0 (Revision:430459)
Bad Build: 56.0.2911.0 (Revision: 430171) 

You are probably looking for a change made after 430275 (known good), but no later than 430276 (first known bad).
CHANGELOG 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/52ca6ae14533e52d9777216a0e7ce9c28508c863..f8d16c7cc9a1ca8e3f861616c495d3a1a9557fc5

From the CL above, assigning the issue to the concern owner 

@clamy - 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.

Review-Url: https://codereview.chromium.org/2405483002

Note: 
 
1.Issue is not seen on Windows 10 and Ubuntu 14.04 usincg chrome latest canary.

Thanks!

FWIW #14 claims r430275 as known good but it's broken on Windows7 here. Also, it doesn't have a bisect for the fix, which should confirm the first bisect for the bug (like it does in #9, supposedly).

I don't see how my change would have fixed this. Unassigning myself.

Since hdodda is having difficulties with bisecting this particular bug, I've narrowed down the bisect from #9 using both 32-bit and 64-bit snapshots, and my initial guess holds: I suspect background tab throttling.

Broken in 56.0.2910.0:
	429859 (good) - 429862 (bad)
	Changelog: https://chromium.googlesource.com/chromium/src/+log/91011136..cdb3463e?pretty=fuller
	Suspecting: r429861 "Teach scheduler about audio state"

Fixed in 56.0.2913.0:
	430348 (bad) - 430357 (good)
	Changelog: https://chromium.googlesource.com/chromium/src/+log/52d00fd5..78bd9c63?pretty=fuller
	Suspecting: r430353 "Do not use audio signal in policy for renderer scheduler"

P.S. Can a non-member like me do *per-revision* bisects without compiling chromium locally?

In addition to #9 and #18: my guess about background tab throttling is based on the fact that the bug doesn't occur when the youtube tab is in foreground.

Tried reverse bisect using old script ,
Good Build: 56.0.2914.0 (Revision:430837)
Bad Build: 56.0.2912.0 (Revision:430205)

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

CHANGELOG URL:
  
https://chromium.googlesource.com/chromium/src/+log/2b5a997b96fc293406416784b9ab23a1e806d3bc..bb2aaf9abe13bdd12fbba17fba9901d430057ca0

From the above CL , suspecting the below change might fixed this issue and assigning it to the concern owner

https://chromium.googlesource.com/chromium/src/+/bb2aaf9abe13bdd12fbba17fba9901d430057ca0

From the CL above, assigning the issue to the concern owner 

@arthursonzogni - 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.

Review-Url: https://codereview.chromium.org/2439903003

Note:
1. While trying reverse bisect with new bisect script, different CL's where generated each time. Hence , proving bisect using old script.
2. Issue is reproduced on Linux and Windows using reported chrome version M56 #56.0.2912.0

Thanks!

#20, another irrelevant bisect because the only possible candidate is about <object data="..."> navigation, also r430265 claimed as known good is actually broken as observed here on Windows 7 (the bug isn't Mac-specific). See #18 for the bisects that do make sense in the context of the bug.

I confirm.
I reproduce the bug on my patch https://crrev.com/430265. Thus it doesn't fixes the bug.

According to some manual tests I made :
https://crrev.com/430269 (BUG reproduced)
https://crrev.com/430300 (BUG reproduced)
https://crrev.com/430348 (BUG not reproduced)

I can't reproduce the bug in https://crrev.com/43034 unlike what it is asserted in #18.

Unassigning myself.

I confirm that the regression occurs between 56.0.2908.0 and 56.0.2909.0. However unable to reproduce in 56.0.2916.0. It might be nice to know which cl caused the regression I'm not sure it's worth more engineering time to pin it down. I'm closing this out, but please reopen if you feel we need to pursue it more.