Bug 176679 - Autoplay blocking no longer applies to WebRTC streams?
Summary: Autoplay blocking no longer applies to WebRTC streams?
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebRTC (show other bugs)
Version: Safari Technology Preview
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-10 17:35 PDT by Andrew Morris
Modified: 2017-09-14 10:07 PDT (History)
4 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Morris 2017-09-10 17:35:07 PDT 
While debugging an unrelated issue we tried going back to just using a video element recently instead of the split video/audio method we were using in Safari, and discovered that audio blocking no longer occurs under this set up.

I've tested this in iOS Beta 9 Safari, Sierra Safari Beta, and Sierra Safari Tech Preview.

Could you try out this jsbin and let us know whether this is intentional?

Publish from any Safari with WebRTC here:
https://output.jsbin.com/jufagah?publish

Test on the target Safari here
https://output.jsbin.com/jufagah?subscribe
Comment 1 youenn fablet 2017-09-11 08:38:03 PDT 
Thanks for the repro tests.
I can reproduce it with older STP versions but not with the latest STP 39a.
Can you try again Andrew?

There were obviously some changes made there, I don't think this was intentional though . We could probably add an API test launching two web processes, one sending and the other receiving to catch such regressions.
Comment 2 Andrew Morris 2017-09-11 17:55:26 PDT 
Yep, can confirm this no longer happens in STP 39. Thanks Youenn.