Bug 176679
| Summary: | Autoplay blocking no longer applies to WebRTC streams? | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Andrew Morris <andrew> |
| Component: | WebRTC | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | eric.carlson, jer.noble, jonlee, youennf |
| Priority: | P2 | ||
| Version: | Safari Technology Preview | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Andrew Morris
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
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
youenn fablet
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.
Andrew Morris
Yep, can confirm this no longer happens in STP 39. Thanks Youenn.