[meta] Publish Proposed Recommendation

[anssiko]

This meta issue tracks progress toward the Remote Playback API Proposed Recommendation (PR) publication. Editor: @mounirlamouri

You see many tickboxes below, but fear not. Almost all of them are administrative in nature and we'll bite that bullet for you with @tidoust. In fact, only the following needs explicit input from the group:

TL;DR: before advancing to PR the group needs to identify whether any of the issues raised since 2017-10-19 are substantive and address them, or whether they should be deferred to the next version of the API.

Please provide your feedback by 2020-01-17.

The general requirements for advancement:

• must record the group's decision to request advancement.
• must obtain Director approval.
• must provide public documentation of all substantive changes to the technical report since the previous publication.
  • https://github.com/w3c/remote-playback/commits/gh-pages
• must formally address all issues raised about the document since the previous maturity level.
  • issues raised since 2017-10-19
• must provide public documentation of any Formal Objections.
  • none

The general should requirements aka nice-to-haves

• should provide public documentation of changes that are not substantive.
• should report which, if any, of the Working Group's requirements for this document have changed since the previous step.
• should report any changes in dependencies with other groups.
• should provide information about implementations known to the Working Group.

The PR-specific requirements for advancement:

• The status information must specify the deadline for Advisory Committee review, which must be at least 28 days after the publication of the Proposed Recommendation and should be at least 10 days after the end of the last Exclusion Opportunity per section 4 of the W3C Patent Policy.
• must show adequate implementation experience except where an exception is approved by the Director,
  • two independent implementations pass the (incomplete, see below) test suite, see test results
  • gap: test automation for other than non-user gesture and non-device specific parts Remote Playback API tests and implementation report #92
• must show that the document has received wide review,
  • wide review received during CR [meta] Publish Candidate Recommendation #73
• must show that all issues raised during the Candidate Recommendation review period other than by Advisory Committee representatives acting in their formal AC representative role have been formally addressed,
  • no issues raised between 2017-10-19 and 2017-11-30
• must identify any substantive issues raised since the close of the Candidate Recommendation review period,
  • issues raised since 2017-11-30
• may have removed features identified in the Candidate Recommendation document as "at risk" without republishing the specification as a Candidate Recommendation.
  • No feature has been identified as being at risk.

[anssiko]

Thanks to your contributions, we were able to reduce the number of open issues blocking Proposed Rec publication significantly.

The remaining Proposed Rec blockers and their current status are the following:

• Remote Playback API tests and implementation report #92 Remote Playback API test automation
  • Automated tests: https://wpt.fyi/results/remote-playback
  • Manual tests (*-manual.html): https://wpt.live/remote-playback/ (GH repo)
  • run manual tests & document results in an implementation report
• Define remote playback interaction with background playback policies #118 Define remote playback interaction with background playback policies
  • PR Add note about playback policies. #131 landed
• RemotePlaybackState enum can become misleading when changing media.src #125 RemotePlaybackState enum can become misleading when changing media.src
  • @mounirlamouri to submit a PR

Process quirk: #92 proposes to add new API surface that requires us to publish a revised CR (incl. conduct wide review for this delta prior), before PR. (WebDriver extensions not added to the specification at this time.)

[anssiko]

With #125 closed, the only remaining Proposed Rec blocker is #92 Remote Playback API test automation.

@Honry is no longer working on this task, so per TPAC discussion @louaybassbouss took an action to figure out a way forward.

[anssiko]

Status update on the publication blockers #130 (comment):

• The group initially explored WebDriver extension API for test automation but chose to not integrate the extension API at this time.
• The group received contributions for automated tests https://wpt.fyi/results/remote-playback and manual tests https://wpt.live/remote-playback/ (*-manual.html) that combined have adequate test coverage.

To show adequate implementation experience and advance the spec to its next maturity stage, the group is expected to create a manual implementation report. Following up on that in #92.

[FritzHeiden]

All tests have been run, results are merged in the test-results repository: https://w3c.github.io/test-results/remote-playback/all.html

Here is a legend of what the headers mean:

• ED29: Edge 129
• SF17: Safari 17 on macOS
• SO18: Safari 18 on iOS
• SP18: Safari 18 on iPad OS

[FritzHeiden]

Added results for Chrome 129 (Ch29) und Chrome Android 126 (CA26): w3c/test-results#226

We noticed that opening the device selection prompt in the tests does not work in any Chrome browser. Chromecast is detected by the browser (e.g. casting works on YouTube), but selecting device in the tests does not work.

[markafoltz]

Yes, I also noticed that the prompt is not shown in Chrome. Do the tests verify that the watchAvailability callback is being invoked with true before prompting?