Able to reproduce this issue on latest stable 66.0.3359.139, on latest canary 68.0.3424.0 using Windows 10, version 1709 with below steps.

1. Launched chrome and started playing Youtube video.
2. Restarted windows without closing chrome
3. After restart didn't login for about 30 sec -- Now able to hear previously played video
4. After logging in chrome is seen with previously opened tabs. 

As per comment#0 this might be related to Windows update. This issue is seen from M-60. Hence considering this issue as Non-Regression and marking as Untriaged. Please change the status if not appropriate.

NOTE: Issue is not seen in Firefox

A bit more background: I noticed this when using RegisterApplicationRestart in Firefox, see:
https://bugzilla.mozilla.org/show_bug.cgi?id=603903

Originally I was planning to use OpenInputDesktop to detect if the desktop was locked on startup, and that worked for Fall Creators Update. But since the April 2018 Update, before login OpenInputDesktop opens the "Default" desktop instead of trying (and failing) to open "Winlogon" as expected. OpenInputDesktop still fails when the session is locked after login, so this seems to be a special case added to fix applications that weren't designed to start on a locked session.

> NOTE: Issue is not seen in Firefox
This issue will soon be showing up in Firefox Nightly, I've opened a bug for it:
https://bugzilla.mozilla.org/show_bug.cgi?id=1462123

Hopefully we can find a way to solve this.

Setting to Blink for larger scope triage. The issue here is visibility being reported, nothing related to video element.

I think this really belongs to a policy in ResourceCoordinator.

pkasting@ can someone from the Windows team own this? Seems like a flaw that could leak information about what a user was doing prior to a restart.

+CC knowledgeable Windows folks about the feasibility of detecting this state.  See also the Mozilla bug referenced in comment 4.

IMO we should never autoplay media (even in the foreground tab) after Chrome is auto-restored.  There are too many cases where this isn't actually what the user wants, and it's easy to manually start media playing again.  That would fix this as a side effect.

I agree with pkasting@'s suggestion that we shouldn't autoplay on Chrome restore, which will fix this as well.

Generally nothing should autoplay unless the page is visible. Is there a reason that Chrome thinks the page is visible in this case?

On restore, only the foreground tab is allowed to autoplay, and then the foreground tab follows the same autoplay rules as new tab behavior. What is the argument for having a different behavior for restore?

Restore is a relatively rare event, so the benefit of autoplaying media after a restore when the user wanted it is small.

Restore frequently happens when the user isn't present (e.g. in the middle of the night when the user is sleeping), so the potential negative effect of autoplaying in this case is relatively high.

So even if we can fix whatever issues here cause Chrome to believe it's visible when it's not, it seems like we'd do better by the user to err on the side of not autoplaying media after a restore, and let them correct us if e.g. they forced an update while watching a YouTube video and want it to continue.

A few thoughts here...

First, IIUC the change here only affects autoplay when Chrome is not visible. I believe everyone agrees that is undesirable; the ideal solution is to ensure that Chrome doesn't think it is visible (this behavior is already enforced for background tabs); this approach would also have other benefits beyond autoplay.

Second, there is no change to autoplay policy when Chrome is visible. Nightly updates that result in Chrome appearing on the desktop (without a login) have not seen a change in behavior. We haven't had a lot of complaints about the autoplay policy in this context AFAICT.

However, there are some legitimate use cases where restore should allow autoplay. Digital signage, kiosk mode are examples where 'hands off' the system should allow a hard reboot or update and let videos play when the system has resumed; it's not clear to me that we should change that behavior at this time.

@11: I have fielded several different complaints about autoplaying after system restart.

Kiosk/signage are generally cases where Chrome is also being run in a dedicated mode (e.g. --kiosk).  I think we should behave differently there.  For normal mode, I still think it'd be better to avoid auto-starting videos in foreground tabs on an automatic restart.

Figuring out how an app was launched by Windows is an inexact science.

Most of our heuristics to tease this apart live in startup_browser_creator_impl.cc around here:
https://cs.chromium.org/chromium/src/chrome/browser/ui/startup/startup_browser_creator_impl.cc?l=143&rcl=2a85860d84f609b51bd8bc8a171cf42ea07e45bc