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

Issue 824653 link

Starred by 7 users

Issue metadata

Status: WontFix
Owner:
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: 2018-05-02
OS: Linux , Windows , Chrome , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

On the new autoplay policy: video doesn't autoplay even when Media Engagement Index threshold has been crossed

Reported by human.p...@gmail.com, Mar 22 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.45 Safari/537.36

Example URL:
https://www.google.com/search?q=last+chrismas+youtube

Steps to reproduce the problem:
1. Go chrome://flags/#autoplay-policy and change it to "Document user activation is required" so we use the new video policy.

2. Open chrome://media-engagement/ , make sure YouTube has already reached the threshold. If not, you can test another website that has instead.

3. Search some videos on Google, for example,  https://www.google.com/search?q=last+chrismas+youtube

4. Click the first YouTube link, in my case, https://www.youtube.com/watch?v=E8gmARGvPlI

What is the expected behavior?
The video should autoplay, because according to https://developers.google.com/web/updates/2017/09/autoplay-policy-changes#new-behaviors the new behavior (which I enabled by toggling the flags) should be:

"Autoplay with sound is allowed if: On desktop, the user's Media Engagement Index threshold has been crossed, meaning the user has previously play video with sound.", which YouTube did in my end.

What went wrong?
However, the video doesn't autoplay. I have to click the video to make it play everytime I come from a different domain.

Did this work before? Yes It starts doing since at most 1 week ago. But before I just use "default" for that flag, so it could just be the default has changed. Anyway, it doesn't work as expected.

Is it a problem with Flash or HTML5? HTML5

Does this work in other browsers? Yes

Chrome version: 66.0.3359.45  Channel: beta
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: 

Contents of chrome://gpu: 
Irrelevant.
 
Cc: mlamouri@chromium.org
Components: -Internals>Media Blink>Media>Autoplay
Labels: Needs-Feedback
Thanks for the bug report. We are currently running a 50/50 experiment on the Beta population with and without the policy enabled to measure the impact. It's possible that your client has it disabled so MEI isn't used to enabled autoplay. However, because you are setting "Document user activation is required", that would still be enabled.

Can you:
- reset the autoplay-policy flag and update the actual result (if my theory is correcty, autoplay should work)
- try on a Chrome 67 build (Canary) and MEI should work as expected

Thanks :)
Using the same steps (Google -> YouTube):

When Autoplay policy flag..

= Default: Video doesn't autoplay
= No user gesture is required.: video auto plays (as expected)
= User gesture is required for cross-origin iframes.: video autoplays
= Document user activation is required.: video doesn't autoplay (the main issue)

I then copied my profile to Chrome Canary (otherwise I won't have enough MEI for YouTube to pass the threshold):

I double checked in chrome://media-engagement/, Youtube.com indeed is still considered as "is high".

Version 67.0.3379.0 (Official Build) canary (64-bit)

The result is exactly the same as beta (see above).



Project Member

Comment 3 by sheriffbot@chromium.org, Mar 23 2018

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
I can't reproduce this :( Could you try with a fresh profile?
It's tedious for me to generate enough Media Engagement Index on a new profile, but I will try.
I successfully reproduced the bug and has some new findings.

The setting is still the same, using "Document user activation is required." 
Tested with Google -> YouTube.

When the score is below lower threshold (0.2), video (cross-domain) doesn't autoplay as expected.

When the score is above lower threshold but under upper threshold, i.e. between 0.2 and 0.3, video (cross-domain) autoplays as expected.

HOWEVER, when the score continues increasing and finally surpasses upper threshold (0.3), it suddenly stops to autoplay -- and this is the bug.

My find MEI report:

Media Engagement
Copy all to clipboard
Setting Name	Setting Value
Min Sessions	20
Lower Threshold	0.2
Upper Threshold	0.3
  Show sessions with no playbacks

Origin	Sessions	Sessions with playback	Audible Playbacks*	Significant Playbacks*	Last Playback	Is High	Is High Changes	Score
https://www.youtube.com/	14	6	10	8	2018-03-26T01:48:45.479Z	Yes	1	0.30	
* These columns are experimental and do not currently affect the MEI score.

And this is exactly when it stops working.

(I knew my session number seems to be less than so-called "min sessions" parameter. But from my observation on my main profile, which has 90+ sessions for YouTube, this parameter doesn't affect the bug.)

 
Typos:

has some->had some
find MEI report->final MEI report
Components: -Blink>Media>Autoplay Internals>Media>Engagement
Owner: beccahughes@chromium.org
beccahughes@, can you PTAL?
Status: Started (was: Unconfirmed)
Confirmed on 67.0.3382.0. This bug only appears after a navigation from another origin e.g. Google -> YouTube. 
Labels: -Pri-2 M-66 ReleaseBlock-Stable OS-Chrome OS-Linux OS-Mac Pri-1
Great find! Thanks beccahguhes@ and OP :)
Project Member

Comment 11 by bugdroid1@chromium.org, Mar 28 2018

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

commit fb3959a7049912b0963ae4c8d4f3598f123a6316
Author: Becca Hughes <beccahughes@chromium.org>
Date: Wed Mar 28 08:49:55 2018

Media Engagement: Fix for incorrect URL

The Media Engagement contents observer was incorrectly using the wrong
URL for top frame navigations. This fixes it so it uses the URL from the
NavigationHandle in a main frame navigation. Sub frame navigations
should continue to use the last committed URL of the web contents.

BUG= 824653 

Change-Id: I9c77b4e36c9c37471808d6c0817eb70c7fea8de1
Reviewed-on: https://chromium-review.googlesource.com/982409
Commit-Queue: Mounir Lamouri <mlamouri@chromium.org>
Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
Cr-Commit-Position: refs/heads/master@{#546438}
[modify] https://crrev.com/fb3959a7049912b0963ae4c8d4f3598f123a6316/chrome/browser/media/media_engagement_autoplay_browsertest.cc
[modify] https://crrev.com/fb3959a7049912b0963ae4c8d4f3598f123a6316/chrome/browser/media/media_engagement_contents_observer.cc

Labels: Merge-Request-66
Project Member

Comment 13 by sheriffbot@chromium.org, Mar 29 2018

Labels: -Merge-Request-66 Merge-Review-66 Hotlist-Merge-Review
This bug requires manual review: M66 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Merge-Review-66 Merge-Approved-66
Approving merge to M66. Branch3359
Project Member

Comment 15 by bugdroid1@chromium.org, Mar 29 2018

Labels: -merge-approved-66 merge-merged-3359
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/559d53cf526f392ab86641872046b79e831ec4b1

commit 559d53cf526f392ab86641872046b79e831ec4b1
Author: Becca Hughes <beccahughes@chromium.org>
Date: Thu Mar 29 21:01:32 2018

Media Engagement: Fix for incorrect URL

The Media Engagement contents observer was incorrectly using the wrong
URL for top frame navigations. This fixes it so it uses the URL from the
NavigationHandle in a main frame navigation. Sub frame navigations
should continue to use the last committed URL of the web contents.

BUG= 824653 

Change-Id: I9c77b4e36c9c37471808d6c0817eb70c7fea8de1
Reviewed-on: https://chromium-review.googlesource.com/982409
Commit-Queue: Mounir Lamouri <mlamouri@chromium.org>
Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#546438}
Reviewed-on: https://chromium-review.googlesource.com/986916
Reviewed-by: Becca Hughes <beccahughes@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#504}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/559d53cf526f392ab86641872046b79e831ec4b1/chrome/browser/media/media_engagement_autoplay_browsertest.cc
[modify] https://crrev.com/559d53cf526f392ab86641872046b79e831ec4b1/chrome/browser/media/media_engagement_contents_observer.cc

Status: Fixed (was: Started)
This is broken again with Version 68.0.3410.2 (Official Build) canary (64-bit)
Status: Started (was: Fixed)
I think this may be related to AutoplayFlags. I will check this on 66-68 and reconfirm.
Labels: -M-66 M-68
I cannot reproduce this on M67 or 68.0.3416.0 on Linux. I tried the following use cases:

1) Open YouTube from search results in same tab
2) Open YouTube from search results in new tab (right click)
3) Open YouTube from search results in new tab (mouse wheel click)
4) Open YouTube directly from link

All of them autoplayed as expected. Please can you update canary and see if it is fixed?
Cc: beccahughes@chromium.org johnpallett@chromium.org
 Issue 835582  has been merged into this issue.
@beccahughes

I indeed cannot reproduce it on newest Canary anymore, Version 68.0.3415.0 (Official Build) canary (64-bit).

But I can still reproduce on newest Beta (Version 67.0.3396.18 (Official Build) beta (64-bit)), which is weird since it was fixed even on Beta before IIRC.
NextAction: 2018-05-02
There is an autoplay bugfix between 68.0.3410.2 and 68.0.3415.0 which I think may have fixed this.

This has been cherry picked to 67 but the latest beta has not been released yet. It should be released in the next couple of days.
The NextAction date has arrived: 2018-05-02
human.peng - there is a new beta 67.0.3396.30 please can you test again?
67.0.3396.30 (Official Build) beta (64-bit) (cohort: Beta)

It's NOT fixed it seems.
but this is fixed on Canary?
Yeah.
Hmm I can't replicate this on Mac 67.0.3396.30. We do have an experiment running on Beta so it is possible this is causing this. Please can you go to chrome://version/ on your beta browser, copy the values under variations and post them here?
Variations	c134752e-b8b72c88
5f419cc9-ca7d8d80
59aeb88e-3f4a17df
31101bd6-3f4a17df
a6674cf-d795f81e
1e528f0f-9fbc5b0e
b130ecb8-2e32ee7e
38eb801c-3f4a17df
47e5d3db-3d47f4f4
125b7f68-c7a5f76
4dc30737-b8a5ea08
589b4e9f-3f4a17df
f9884634-659882c0
121ae2bc-ee24275d
ceff87ec-3f4a17df
44827ee5-f23d1dea
5e3a236d-59e286d0
9773d3bd-f23d1dea
93731dca-82fd7ac9
9e5c75f1-8de02276
f79cb77b-3f4a17df
4ea303a6-f5d1e975
d92562a9-cfe3c2ea
7aa46da5-c946b150
2b33233e-881ca6c9
2c1d398c-f23d1dea
58a025e3-c2b41702
ad6d27cc-1627c3cf
2a32876a-ca7d8d80
ff29b1bd-736621bc
f3ea30a0-ca7d8d80
4bc337ce-69465896
9a2f4e5b-485e96a8
17507c76-3d47f4f4
494d8760-52325d43
3ac60855-486e2a9c
f296190c-b52e3392
4442aae2-d7f6b13c
ed1d377-e1cc0f14
12e17bc5-e1cc0f14
75f0f0a0-d7f6b13c
e2b18481-6e3b1976
e7e71889-4ad60575
b1ceb06f-3ac589b9


Status: WontFix (was: Started)
Aha! Yes you are in a group that has unified autoplay / media engagement disabled which is what is causing this. Unfortunately the only way to override this would be to use command line flags.

I'll close this as WontFix for now.

Sign in to add a comment