[latexr]

That’s an unfair characterisation. It’s just restoring windows, some of which happen to be browser windows, which then load a website with auto-playing video or audio that (unsurprisingly) starts playing. No one is selling it as a feature to “play sound when waking up from sleep”. I bet that if you configured the browser to never auto-play, this wouldn’t happen.

To clarify, because commenters seem to be misunderstanding my point: I’m not defending the functionality, I think it’s wrong. My sole quarrel is with the characterisation that Apple is selling it as a feature, when they’re not. Let’s not ascribe wrong (or at best unknown) motivations to behaviours, as that makes is less likely they will be fixed.

[dspillett]

No one is selling it as a feature, no, but I would still consider it an OS level bug, and a security one at that. Focusing on the browser is a step away from the point: if I'm not signed in, I don't want sound playing from any app⁰.

I've had Windows do something similar, a media player deciding to unpause when coming up from hibernate (this was before Windows seemingly broke hibernate) and for some reason being at full volume, and it was a fair few seconds before I was able to login, get to that app, and hit pause again. It didn't leak anything sensitive (Hey everyone, this guy watches Stargate!) but it made me “that guy we all hate” on the train… Again it is the app that is responsible for making the sound, but I think at that point the OS shouldn't let it.

<glasses tint="rose">I miss the times when laptops had physical volume sliders…</galsses>

To me this has the feeling of making a mountain out of a molehill, but I don't think there is any denying that the molehill itself exists and to others it might be more than the very minor irritation it could be to me.

> I bet that if you configured the browser to never auto-play, this wouldn’t happen.

I bet that no matter how tightly you try to control that, some advertiser will find a way to override it to make sound play, and sods law says that will happen when you most want your waking laptop to be quiet. Blocking audio while not signed in at the OS level is a safer gate.

----

[0] Actually, there is an exception there: if the machine has locked due to input inactivity, I want audio I'm listening to continue and notification pips to come through. There is a distinction between OS restarting (from [re]boot, wake, etc.) and local console not logged in due to input timeout, in how I'd prefer things to behave.

[latexr]

> No one is selling it as a feature, no

That’s all I’m saying.

> but I would still consider it an OS level bug

I agree.

[mgoetzke]

To clarify it restores windows AFTER a reboot, BEFORE i login.

What RIGHT does it have to create processes with a user BEFORE I authenticate to the machine ?

[latexr]

Yes, I understand, I have encountered that as well and I agree it shouldn’t happen.

My only quarrel is with the other user implying Apple is selling this as a feature. I have my fair share of criticism of Apple and other tech companies, but let’s please not let blind hate take over and dilute arguments.

[eptcyka]

Does it matter if the end result is that the browser plays audio before you've authenticated your user session?

[latexr]

The characterisation matters, yes. Because when you ascribe wrong motivations out of perceived spite, it makes it less likely the people who can fix it want to do so.

I’m not defending the bug, I’m replying to the post below it.

[chx]

I do not think the user particularly cares whether it was an intentional feature or an unfortunate byproduct of features and bugs when they open a laptop in a classroom or a meeting and it starts blaring the music they listened to before closing it.

[Jerrrrrrry]

Some areas of expertise require so much work, it nearly prevents the student from learning to appreciate the intent, the craft, itself.

It's like being literally unable to dog

Opening a laptop, even if the last activity was blaring obnoxious carnival music, should _allow_, not _demand_ the user to resume their last function - which was explicitly to _pause_ the laptop, by closing the lid.

If I close the lid, I am done with the computer and video; it is obvious that I am done right now - the OS/browser would be alerted of LidDown, and I would expect the OS to tell the browser to Pause (via some new javascript media API that I am sure exists), pagefile ram if possible/needed, and dump all console.logs to a temp directory, in case restarting from hibernation goes awry.

If I open the lid, I am attempting to use the computer. The previous quest can be pertinent or moot; but it would be oddly assumptive (against the ethos of general computing) to _automagically_ resume (especially a paused) playback just from first button press - at least give me the option to explore, format, or rename the thing.

[AstralStorm]

You're asking the OSes to actually implement proper session management and centralized leak controls?

It has never happened before...

[Jerrrrrrry]

The thread shouldn't pause with AudioContext frozen in an "active" status. The thread unpauses, the AudioContext resumes before the next frame (whever thatll be) comes to remember to pause it.

Windows 7 with Youtube can figure out - even with hibernation breaking audio/bluetooth on windows - then surely the most expensive company and OS 15 years later has made an inkling of progress (if that was ever their intention)