I'm all for letting the user block autoplay, I'm just not for Chrome's solution.
Example where the change sucks. Chat apps. Chat apps want to make a "ping" sound when a new message arrives. Can't unless the user interacts. I reboot my machine and or log out. I restart Chrome, it reloads tabs, tabs that have my chat sessions in them. This change basically means I have to go to each tab and click something before I'll start getting notification sounds.
You might say a solution is to use the notification API but the notification API has other issues. One is that without warning message contents gets displayed in the notification. That content might not be something I want someone else to see so I have chosen not to opt into the notification API instead preferring just a sound so I can choose if it's safe to view.
A better solution, at least for chat, is to let the user whitelist the page. That's not an option with Chrome's new system.
I agree that this change to Chrome is badly done. The problem is that if an AudioContext is created when the page loads (from a direct URL request), then the AudioContext is automatically paused even if that AudioContext is not currently playing audio. That breaks a lot of code even in games where the user is required to click something before audio playback begins. So the fix Chrome implemented goes beyond stopping autoplay. Now I have to add context.resume() to the play button code in every page. ugh!
At least a little of the uproar is due to ppk doing some version of this same talk last June, and everyone went similarly bananas then: https://twitter.com/freshmango/status/743380493614333952
So at least a little of the uproar this time is exasperation. Let's be honest, the slide is baity. I for one was hoping ppk might have toned it down a little because I just hate seeing the community like this. As you were there, you know PPK's point is well-meant. However repeated use of this slide causes me to despair. At best it's intentionally baity, at worst it's intentionally divisive. The community in general seems to assume the latter every time. Deliberately causing argument (as opposed to discussion) is not a pleasant thing.
Back in the day when you could write your CSS by hand your stored procedures by hand, your HTML by hand and have the thing render in milliseconds, bypassing whatever crap was generated by whichever language or framework you were supposed to be helped by, it was fun. Even if I had to write workarounds for IE, always IE.
When the Javascript frameworks came into the picture, changing (breaking up) every other week, taking the control from the developer and adding a lot of weight for not a lot of functionality, then it stopped being fun.
Exactly. I have been doing backend (Python, Django, databases, servers, Linux, caches, etc) and lot of front end (vanilla JS, jQuery, micro-frameworks, CSS3, Sass, Stylus, HTML5) for 7-8 years and have been thinking about those points in recent years. Totally agree with the main ideas:
1- Front end development is getting too complicated, too much sophisticated and with too many abstractions/layers. That's prone to errors.
2- You should have a "basic knowledge" of what's going on behind your abstractions.
3- Don't follow trends. Think like an engineer and choose the right tools.
It's all about managing complexity. Totally agree with your and ppt opinion. That guys are just looking for a way to joke, instead of focusing on real problems.
For me another big well-crafted hint is speed. This is also one of the things that isn't tied to a particular time, but I think the release of yslow and the accompanying rules for frontend performance optimization around 2007 were a game changer.
When you see that developers take care about things like optimizing images, avoiding bloat, reducing HTTP requests and so forth, it is clearly a hint, that they know their craft.
Thanks Mitch Wells! Yeah I'm working on a web synth as well, and touchend is not a good solution. Handling touchend on first touch, then from then on touchstart works is a better solution. I think you can avoid the ios9 fix prompt by playing on touchend of the first note that's hit. Just keep a state for hasFirstNoteBeenPlayed, and then play a sound on touchend. e.g. my touchend event winds up calling this function: stopNote:function(note){ //'this' is the object that defines the stopNote function in this case, not a dom node if(!this.hasFirstNoteBeenPlayed){ var oscFix = this.options.audioContext.createOscillator(); oscFix.type = 'sine'; oscFix.frequency.value = 100000; oscFix.start ? oscFix.start() : oscFix.noteOn(); oscFix.stop ? oscFix.stop() : oscFix.noteOff();
this.hasFirstNoteBeenPlayed = true; } ...
So the first press won't work, but subsequent presses will work.
I think, they've fixed this in WebKit, but it probably hasn't been released, yet. I doubt it will be more than a month from official release. Here is the commit: https://github.com/WebKit/webkit/commit/70969efa4aa9425ceb04346a468de832f88945ac
The same problem and fix has been reported for createjs. Can someone who has reported a fix on here try this test out for me.
Press and hold the "trigger" for 2 seconds and then release. This should still trigger your "click" and "touchend" events but for me it doesn't trigger the audio to play if you press and hold.
The touchend solution seems to work fine for audio and video tags with iOS 9.0.2. If you use a click event it also works (minus the lag). There still seems to be some issue with prolonged touch (over 2 seconds) but I think this could be within specs as Safari might consider it a "cancel touch".
So I'm not alone in this issue. I like touchstart because it creates non-laggy clicks on mobile, but it messes me up in terms of audio. I might just use a click event in the beginning to load the audio and then use touchstart afterwards.
Just to add in case it isn't clear, the touchend only needs to happen on the first instance of audio. I'm updating my web audio synth so that if you are running an iOS, it makes you click ok before you start and on touchend of "ok", it triggers the first sound.
After that touchstart does trigger sounds.
I am facing a bigger problem in that iOS 9 seems to be adding lots of noise to web audio that I don't think was there before. The noise actually makes my synth unusable on iPhone. arrrg.
Awesome, thanks, guys! I changed my "mousedown touchstart" event handler in Soundslice to a single "mousedown" and it works. Sounds like there are two solutions -- use "mousedown" or "touchend".
Chrome’s web audio change is bad news – ChatApp on May 23, 2018:
I'm all for letting the user block autoplay, I'm just not for Chrome's solution.
Example where the change sucks. Chat apps. Chat apps want to make a "ping" sound when a new message arrives. Can't unless the user interacts. I reboot my machine and or log out. I restart Chrome, it reloads tabs, tabs that have my chat sessions in them. This change basically means I have to go to each tab and click something before I'll start getting notification sounds.
You might say a solution is to use the notification API but the notification API has other issues. One is that without warning message contents gets displayed in the notification. That content might not be something I want someone else to see so I have chosen not to opt into the notification API instead preferring just a sound so I can choose if it's safe to view.
A better solution, at least for chat, is to let the user whitelist the page. That's not an option with Chrome's new system.
Chrome’s web audio change is bad news – Steven Estrella on May 10, 2018:
I agree that this change to Chrome is badly done. The problem is that if an AudioContext is created when the page loads (from a direct URL request), then the AudioContext is automatically paused even if that AudioContext is not currently playing audio. That breaks a lot of code even in games where the user is required to click something before audio playback begins. So the fix Chrome implemented goes beyond stopping autoplay. Now I have to add context.resume() to the play button code in every page. ugh!
About the PPK talk and tweet – Dave on February 13, 2017:
At least a little of the uproar is due to ppk doing some version of this same talk last June, and everyone went similarly bananas then: https://twitter.com/freshmango/status/743380493614333952
So at least a little of the uproar this time is exasperation. Let's be honest, the slide is baity. I for one was hoping ppk might have toned it down a little because I just hate seeing the community like this. As you were there, you know PPK's point is well-meant. However repeated use of this slide causes me to despair. At best it's intentionally baity, at worst it's intentionally divisive. The community in general seems to assume the latter every time. Deliberately causing argument (as opposed to discussion) is not a pleasant thing.
About the PPK talk and tweet – Leticia on February 12, 2017:
Back in the day when you could write your CSS by hand your stored procedures by hand, your HTML by hand and have the thing render in milliseconds, bypassing whatever crap was generated by whichever language or framework you were supposed to be helped by, it was fun. Even if I had to write workarounds for IE, always IE.
When the Javascript frameworks came into the picture, changing (breaking up) every other week, taking the control from the developer and adding a lot of weight for not a lot of functionality, then it stopped being fun.
About the PPK talk and tweet – Pedro on February 11, 2017:
Exactly. I have been doing backend (Python, Django, databases, servers, Linux, caches, etc) and lot of front end (vanilla JS, jQuery, micro-frameworks, CSS3, Sass, Stylus, HTML5) for 7-8 years and have been thinking about those points in recent years. Totally agree with the main ideas:
1- Front end development is getting too complicated, too much sophisticated and with too many abstractions/layers. That's prone to errors.
2- You should have a "basic knowledge" of what's going on behind your abstractions.
3- Don't follow trends. Think like an engineer and choose the right tools.
About the PPK talk and tweet – Oleh Kuchuk on February 11, 2017:
It's all about managing complexity. Totally agree with your and ppt opinion. That guys are just looking for a way to joke, instead of focusing on real problems.
About the PPK talk and tweet – Felix Niklas on February 10, 2017:
Didn't expect that you'd get so much negative feedback for that tweet. I enjoyed it! Thanks for the write up!
The history of ‘this website is well-crafted’ hints – Ramiro on May 5, 2016:
For me another big well-crafted hint is speed. This is also one of the things that isn't tied to a particular time, but I think the release of yslow and the accompanying rules for frontend performance optimization around 2007 were a game changer.
When you see that developers take care about things like optimizing images, avoiding bloat, reducing HTTP requests and so forth, it is clearly a hint, that they know their craft.
iOS 9 problems with web audio – Jason on November 11, 2015:
Thanks Mitch Wells!
Yeah I'm working on a web synth as well, and touchend is not a good solution.
Handling touchend on first touch, then from then on touchstart works is a better solution.
I think you can avoid the ios9 fix prompt by playing on touchend of the first note that's hit. Just keep a state for hasFirstNoteBeenPlayed, and then play a sound on touchend.
e.g. my touchend event winds up calling this function:
stopNote:function(note){
//'this' is the object that defines the stopNote function in this case, not a dom node
if(!this.hasFirstNoteBeenPlayed){
var oscFix = this.options.audioContext.createOscillator();
oscFix.type = 'sine';
oscFix.frequency.value = 100000;
oscFix.start ? oscFix.start() : oscFix.noteOn();
oscFix.stop ? oscFix.stop() : oscFix.noteOff();
this.hasFirstNoteBeenPlayed = true;
}
...
So the first press won't work, but subsequent presses will work.
iOS 9 problems with web audio – Nikolay Tsenkov on October 13, 2015:
I think, they've fixed this in WebKit, but it probably hasn't been released, yet.
I doubt it will be more than a month from official release.
Here is the commit: https://github.com/WebKit/webkit/commit/70969efa4aa9425ceb04346a468de832f88945ac
iOS 9 problems with web audio – ism on October 10, 2015:
I'm having problems with wad.js too. Anybody got a workaround for that library? touchend, mousedown, etc., don't resolve issue.
iOS 9 problems with web audio – Carl on October 6, 2015:
The bug posted about this says it's closed. https://bugs.webkit.org/show_bug.cgi?id=149367
Does that mean it's getting updated in a new release?
iOS 9 problems with web audio – Jonny on October 6, 2015:
The same problem and fix has been reported for createjs. Can someone who has reported a fix on here try this test out for me.
Press and hold the "trigger" for 2 seconds and then release. This should still trigger your "click" and "touchend" events but for me it doesn't trigger the audio to play if you press and hold.
Thanks
iOS 9 problems with web audio – Arnaud Leyder on October 2, 2015:
The touchend solution seems to work fine for audio and video tags with iOS 9.0.2. If you use a click event it also works (minus the lag). There still seems to be some issue with prolonged touch (over 2 seconds) but I think this could be within specs as Safari might consider it a "cancel touch".
iOS 9 problems with web audio – Yaphi on October 2, 2015:
So I'm not alone in this issue. I like touchstart because it creates non-laggy clicks on mobile, but it messes me up in terms of audio. I might just use a click event in the beginning to load the audio and then use touchstart afterwards.
iOS 9 problems with web audio – Thorsten Schomburg on September 24, 2015:
FYI: Same problem with starting a video. The solution with the touchend event does not work for a slow touch (hold down the finger half a second)
iOS 9 problems with web audio – Mitch Wells on September 24, 2015:
Just to add in case it isn't clear, the touchend only needs to happen on the first instance of audio. I'm updating my web audio synth so that if you are running an iOS, it makes you click ok before you start and on touchend of "ok", it triggers the first sound.
After that touchstart does trigger sounds.
I am facing a bigger problem in that iOS 9 seems to be adding lots of noise to web audio that I don't think was there before. The noise actually makes my synth unusable on iPhone. arrrg.
www.websynths.com
iOS 9 problems with web audio – Jay Oster on September 19, 2015:
FYI, this bug has been reported upstream to Apple/WebKit: https://bugs.webkit.org/show_bug.cgi?id=149367
iOS 9 problems with web audio – Adrian Holovaty on September 19, 2015:
Awesome, thanks, guys! I changed my "mousedown touchstart" event handler in Soundslice to a single "mousedown" and it works. Sounds like there are two solutions -- use "mousedown" or "touchend".
iOS 9 problems with web audio – Joe Weiss on September 19, 2015:
I came here to post the touchend solution. I can also confirm that it works.