1462123 - Content loads and runs before user has logged in

Status: RESOLVED WONTFIX

(Core :: Widget: Win32, defect, P3)

Description

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Bug 603903 registers Firefox to be restarted by Windows if it was running when Windows last shut down. Originally this would only apply to restarts for updates or installations, but Windows 10 Fall Creators Update (first previewed in build 16251) introduced the "Improved Boot Up Experience" [1], which extended this to apply to all shutdowns.

At the same time (as far as I can tell), a change was made so that, if a password is required on startup, restarted applications are started *before* the user logs in. See the discussion in bug 603903 comment 35 through 39 for why this is a generally undesirable time for a web browser to restore the user's session and run/play content. The simplest irritation is a video that plays audibly but invisibly (and uncontrollably) if it had been playing when Windows shut down.

The original plan was to use OpenInputDesktop to check whether the login screen was displayed; if OpenInputDesktop failed we could assume that the user was interacting with the "Winlogon" Desktop, which we did't have permission to open. Then we could just wait for a WM_WTSSESSION_CHANGE message indicating that the session was unlocked.

However in Windows 10 April 2018 Update the behavior of OpenInputDesktop changed so that before login it successfully opens the "Default" Desktop, as it would do normally when the session is not locked. Locking the screen after login still makes OpenInputDesktop fail, so this seems to be a workaround to fix applications that weren't expecting to be started with a locked session. This makes me concerned that Microsoft is trying to make pre-login behavior completely indistinguishable from normal in order to fix applications that don't handle locking properly, which leaves no path for detecting pre-login.

I don't currently have an idea for how to proceed with this. I reported this for Chromium, which has the same issue (see the See Also link).

[1] https://blogs.windows.com/windowsexperience/2017/07/26/announcing-windows-10-insider-preview-build-16251-pc-build-15235-mobile/

Comment 1

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

This may be mitigated somewhat by bug 1376321, blocking autoplaying videos (with sound), now shipping in Nightly.

Comment 2

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

I did a little more exploration:
- OpenInputDesktop still works to detect when the password prompt or Ctrl+Alt+Del screen is up
- The rest of the time at the login/lock screen, there is a "Lock Screen" app running. This seems to be found via the following chain of registry values, terminating in the paths for the packages under the family name:

<package family name> = HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lock Screen\LockAppAumId
<package name list> = key names under HKEY_CLASSES_ROOT\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\Repository\Families\<package family name>
for each <package name> in <package name list>
  HKEY_CLASSES_ROOT\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\PackageRepository\Packages\<package name>\Path

If we check that the foreground window is from an image in that directory, then we know the lock screen is up.

We might check for either of these conditions on startup and disable autoplay...

Comment 3

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Just a note to anyone watching this that there is some activity on the Chromium bug now (the See Also link)