- From: Mark Foltz via GitHub <sysbot+gh@w3.org>
- Date: Fri, 24 Mar 2017 19:51:30 +0000
- To: public-secondscreen@w3.org
@anssiko Here is an update on feature completeness in Chrome. # Controlling UA ## 2-UA mode This has been implemented on Chrome Desktop and Android for some time. It is compatible with Google Cast devices and our [Google Cast for Education](https://chrome.google.com/webstore/detail/google-cast-for-education/bnmgbcehmiinmmlmepibeeflglhbhlea?hl=en-US) application. *Note:* Presentations using the Cast for Education app as a receiver do not support `reconnect()`. ## 1-UA mode This is implemented on Chrome Desktop and planned to be enabled by default in M59 stable (releases in early June). We have just landed support for `reconnect()` to 1-UA presentations and it should be available in M59 dev next week. # Receiving UA ## 2-UA mode There is still no timeline for implementing this in Chrome. The Cast for Education app currently uses a polyfill to implement the `PresentationReceiver` interface. I would characterize this as _at risk_. ## 1-UA mode This is implemented in Chrome for Desktop and planned to be enabled by default in M59 stable. The recent spec changes around sandboxing flags for the receiving browsing context are not yet implemented, but should be available in M59 or M60. # Other features The late breaking change to restrict the API to secure contexts will require us to do outreach to affected sites and gather feedback on a timeline for deprecation on insecure contexts. This process is just starting. I would characterize it as _at risk_ if it is part of the exit criteria since we don't know what timeline we are looking at yet. -- GitHub Notification of comment by mfoltzgoogle Please view or discuss this issue at https://github.com/w3c/presentation-api/issues/406#issuecomment-289126884 using your GitHub account
Received on Friday, 24 March 2017 19:51:37 UTC