julien.etter@ Thanks for the issue.

Tested this issue on Windows 7 and 10 on the reported version 66.0.3359.139, latest Stable 66.0.3359.181 and Canary 68.0.3433.0 by following the below steps.

1. Launched Chrome and downloaded the given zip file.
2. In chrome://flags, can see the flag 'Autoplay policy' set to default.
3. launched launcher.html and clicked on 'launch Window' button, can observe that audio.html file is opened in a new window and audio is not auto played.
3. clicked on 'Detect Window' button and here as well can observe that audio.html file is opened in a new window and audio is not auto played.
Attached is the screen cast of the steps followed for reference.

Request you to check and confirm if anything is missed from our end in triaging the issue.

Thanks..

Deleted: 843579.mp4 770 KB

	843579.mp4 770 KB View Download

Hello Susan,

This is not exactly the use case, and I am wondering if, by running it on a local drive, might have used another set of policies that would not demonstrate my specific use case.

The use test files must be served from a web server to demonstrate my case.
The "detect window" button should work but does not
The "launch window" button should work (and work in my case, not from the local drive)

You may have discovered a potential other issue, but I do not know the autoplay policy related to local drives vs web domain

Best regards

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

julien.etter@ Thanks for the update.

Tested the issue as per comment #4 by launching the files from server on Windows 10, Mac OS 10.13.3 and Ubuntu 14.04 and the issue seems to be inconsistent.
Able to reproduce the issue on reported version 66.0.3359.139, latest Stable 66.0.3359.181, latest Dev 68.0.3432.3 and Canary 68.0.3434.0.
Issue seems to be fixed on the latest Beta 67.0.3396.48.

Attached are the screen casts for reference.

As the issue is inconsistent, marking this issue as Untriaged and requesting someone from Dev team to look into this issue and help further.
Removing the 'Needs-Bisect' label. Please feel free to add back if further triaging is required.

Thanks..

Deleted: 843579-Canary-Bad.mp4 1.3 MB

	843579-Canary-Bad.mp4 1.3 MB View Download

Deleted: 843579-Beta-Good.mp4 1.5 MB

	843579-Beta-Good.mp4 1.5 MB View Download

Thank you Susan,
The problem was related to the new autoplay policy
https://developers.google.com/web/updates/2017/09/autoplay-policy-changes
which was then rolled back in 66.0.3359.181
Is it possible my problem is now dormant and will reappear when the policy comes back with version 70 in October?

I can reproduce in 69.0.3457.0.

What is happening is launching a window with window.open is treated as a navigation from the current window. This means that we carry over the gesture if the new window and the current window are both on the same eTLD+1.

Using window.open to open a blank window and then setting the href is treated as a navigation from the new window.

If we use window.open to update the URL on the window then this will have the same effect as setting the href. If the new window had a gesture that should carry over then it would carry over.

In terms of autoplay this is the correct behavior.

The NextAction date has arrived: 2018-06-19

Using window.open blank on a named window is the only way to get a handle on an already existing window before setting the href “back” to the parent window’s domain.
Will there be any alternative carrying on the gesture?

If you use the same name when using window.open it should get the existing window e.g.

window.open(URL, 'test');  // opens new 'test' window.=
window.open(URL2, 'test'); // opens in existing 'test' window

Yes indeed, but you might want to call JavaScript methods directly on the already existing window rather than set its href if didn’t exists in the first place

If it didn't exist in the first place you can just call window.open(URL, 'test') and it will return a reference to the new window that you can use to call JS methods.

Not if the url is different and your intent is not to reload the window content if it already exists

Can't you just hold onto a reference to the window object when you first open it?

Nope, that is the point, the parent window is a website

Are you trying to use window.open to get a reference to the parent window?

No, typical use case is a website, not SPA, where when you click on “preview”, audio or video, your either open a new window to handle your “player”, or, if the window already exists, you use js to handle the already existing window as an SPA, not changing its href.

If I do the following it works in 69.0.3467.0:

1) Navigate to https://videojs.github.io/autoplay-tests/
2) Click anywhere on the document to give the document a user gesture
3) Open Devtools > Console
4) Run window.open('https://videojs.github.io/autoplay-tests/plain/attr/autoplay.html', 'test')
5) New page opens and autoplays
6) Go back to previous tab and run:

w = window.open('', 'test')
w.location.href = 'https://videojs.github.io/autoplay-tests/plain/attr/autoplay.html?new=1'

7) New tab is reloaded and video is autoplayed

Hello Becca,
Yes, everything works as expected since the rolled back Autoplay policy 66.0.3359.181
Please see comment 7 about dormant problem