I don't know, this seems like a good compromise to me. Some apps (calendar) would be absolutely crippled without them. For everything else, I've just never turned them on in the first place.

> I wish there were a permission pop-up before playing sound at all

The browser can't actually play sound unless 1) it's triggered as the result of a user action (such as a mouse click) or 2) if you've often listened to sound on that page in the past.

My answer to this is that the calendar just does not need to be a web app. Weakening a primary advantage of everything else on the web just so that my calendar can be a web app seems like a poor trade-off.

Re: sound, "Triggered as the result of a user action" is not a high enough bar.

> the calendar just does not need to be a web app

And the chat app, and the email app, and the social media app (other opinions about social media notwithstanding). I think each of these things have their own legitimate use for notifications.

I guess it's the point of "weakening a primary advantage". I don't see how it's weakened (or rather, I don't see how it's a problem) when the notifications are on a per site permission. Especially so when the notifications can be turned off completely per browser.

> Re: sound, "Triggered as the result of a user action" is not a high enough bar.

I'm with you on this. Although it took until this thread for me to realize that sound at all should be a permission.

The world would be better off if social media apps did not have notifications.

Calendars are far more useful as web apps than other incarnations; you can open them anywhere and don't have to carry a specific artifact with you to do it.

a web view for caldav is just fine (and how I use outlook currently); but for notifications a proper program is definitely preferable.

the flashing/buzzing/squawking device in your pocket does this quite well.

> The browser can't actually play sound unless 1) it's triggered as the result of a user action (such as a mouse click) or 2) if you've often listened to sound on that page in the past.

The point is that a click should not give the website permission to play audio - that should be handled much explicitly and not just the user selecting text or some other interaction. Besides, last time I checked Firefox still let AudioContext play sound without any user interaction even though the <audio> element has more restrictions. Which is another problem: the HTML + JS spec is too bloated to properly secure things.

this seems like a pretty silly criticism - you have a feature that is both gated behind a per-site permission prompt and that has an option to globally turn it off, and you're still grumpy that it exists?

if you don't like it turn it off. arguing that things shouldn't exist just because you choose not to use them is pretty selfish.

I mean... it does exist now, and I don't advocate taking it out since people have probably come to rely on it for some reason. Defaults matter, though, and I suspect[0] that a minority want this default.

[0]- With only anecdotes supporting my suspicion; I haven't done a rigorous study.

It seems silly to ask for a release to be crippled just because a page does something obnoxious inside its own space. The solution to that is a URL allowlist or blocklist.