Switch off Legacy WebRTC API flag by default
Created attachment 312615 [details] Patch
Comment on attachment 312615 [details] Patch Seems fine, but you need to update. Does this really belong in experimental settings if it's off?
Thanks for the review. (In reply to Sam Weinig from comment #2) > Comment on attachment 312615 [details] > Patch > > Seems fine, but you need to update. Does this really belong in experimental > settings if it's off? Some of the experimental features are activated by default, others are not. Plan is to remove that option altogether if we see that switching it off is fine. We could then get rid of any legacy API code.
Created attachment 312637 [details] Patch for landing
Comment on attachment 312637 [details] Patch for landing Clearing flags on attachment: 312637 Committed r218169: <http://trac.webkit.org/changeset/218169>
All reviewed patches have been landed. Closing bug.
Know this is too late but I'm not happy with this switch enabled by default. Already too many work has been required to make an alignment in video-related scripts across browsers which made harder for developers to move fast. e.g. Frequent change on autostart policy (this is getting better recently though), No MediaSourceExtension API support in iOS Safari, No h.264 support in Chrome Android etc.
(In reply to Takahiro Ichihashi from comment #7) > Know this is too late but I'm not happy with this switch enabled by default. Providing legacy API support within WebKit would just add another flavor of well known but not well defined APIs. It makes it somehow easy at the beginning and painful at the end. adapter.js is providing legacy API on top of WebKit API. I think it will make a better job at unifying the behaviors of no-longer specified APIS between browsers. > Already too many work has been required to make an alignment in > video-related scripts across browsers which made harder for developers to > move fast. e.g. Frequent change on autostart policy (this is getting better > recently though), No MediaSourceExtension API support in iOS Safari, No > h.264 support in Chrome Android etc. The WebRTC community is working on fixing discrepancies between the different implementations. Agreed that it will take some time though. WebKit target is to support WebRTC 1.0 spec once it gets finalized.
(In reply to Takahiro Ichihashi from comment #7) > Know this is too late but I'm not happy with this switch enabled by default. > Already too many work has been required to make an alignment in > video-related scripts across browsers which made harder for developers to > move fast. e.g. Frequent change on autostart policy (this is getting better > recently though), No MediaSourceExtension API support in iOS Safari, No > h.264 support in Chrome Android etc. @ultravistor - note that adapter.js has been updated to work with Safari, so you can use it to decrease the cross-browser differences.
> adapter.js is providing legacy API on top of WebKit API. > @ultravistor - note that adapter.js has been updated to work with Safari, so you can use it to decrease the cross-browser differences. Thanks, now I really get it (following sentences in your blog post). "Many sites polyfill API support through the open source adapter.js project. Updating to the latest release is one way to cover for the API gap, but we recommend switching to the APIs listed in the specification." I will take a look into the adapter.js and try to migrate some of their polyfills. https://github.com/webrtc/adapter > The WebRTC community is working on fixing discrepancies between the different implementations. > Agreed that it will take some time though. > WebKit target is to support WebRTC 1.0 spec once it gets finalized. Yes. Baseline is that we are all happy to have webrtc finally landed in most major browsers. Thanks for your hard work.