Contact emails
zqz...@chromium.org, mlam...@chromium.org
Spec
https://wicg.github.io/mediasession/
TAG review: https://github.com/w3ctag/spec-reviews/issues/149
Summary
The MediaSession API allows websites to customize media metadata enabling control of media in page from outside the page, such as platform UI, media keys etc. In addition, the API also allows some specification of the out-of-page UI like media title, subtitle, etc.
Explainer: https://github.com/WICG/mediasession/blob/master/explainer.md
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/dLWDxYgxzQ8/vXt0ntWFNBwJ
The spec has changed significantly since the Intent to Implement. The scope has been reduced and no longer includes audio focus. It also moved to WICG and the contacts have changed.
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
This Intent to Ship is Android only (excluding WebView). While there are plans to bring the API to other platforms, it will not be exposed until it is being used, to allow for feature detection.
Demo links
https://xxyzzzq.github.io/sandbox/media-session/full-test.html
https://beaufortfrancois.github.io/sandbox/media-session/playground.html
https://beaufortfrancois.github.io/sandbox/media-session/slow-connection-with-service-worker.html
Interoperability and Compatibility Risk
* Backward compatibility risk doesn’t exist since this is a new API.
* Apple was implementing an earlier version of this API (https://bugs.webkit.org/show_bug.cgi?id=145411), and is actively involved in polishing the API on GitHub issue tracker.
* Mozilla expressed interest before but no public signal recently. They gave positive feedback regarding the scope of the API in face to face conversations.
* No feedback from Microsoft.
* Web developers: positive, there was early involvement from SoundCloud.
OWP launch tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=497735
Entry on the feature dashboard
https://www.chromestatus.c intent to shipom/features/5639924124483584
As a chromium custom-embedder dev, i know the "MediaSession" concept is due to an AudioFocus bug.The explainer says MediaSession API has 2 purposes: for metadata display, for `allowed` play controls. So i guess there is some "concept shift"?
IMO, these APIs give pages too much control over use can locally overwrite/modify. e.g. There is a video page, which says, (in its JS code), "You are not seek forward unless having the AD video pieces viewed first...", so MediaSession API just gives much convenience for them to do this.
On Thu, 12 Jan 2017, at 15:55, Philip Jägenstedt wrote:
> Happy to see this making progress. Things have changed quite a bit since
> I
> was involved, so I've tried to take a look with fresh eyes.
>
> *Metadata*
>
> The members of MediaMetadata are now mutable. I wondered if that really
> works for FrozenArray<MediaImage>
> <https://github.com/heycam/webidl/issues/265>. It should work per Web
> IDL,
> but results in some funny behavior. Are there tests for this? This is the
> first such attribute in Blink and probably on the web platform, and Boris
> suspects that readonly attribute + setter might be more sensible
> <https://github.com/WICG/mediasession/issues/176>.
We do have tests. I actually have a page open to upload them to
web-platform-tests but didn't got around this.
> Mutability also means that MediaMetadata internally knows which session
> owns it. The case where the same metadata object is assigned to multiple
> sessions is handled in the spec and matches what's implemented, but is a
> bit unusual:
> metadata = new MediaMetadata();
> navigator.mediaSession.metadata = metadata;
> iframe.contentWindow.navigator.mediaSession.metadata = metadata;
> // now navigator.mediaSession.metadata is null
>
> Given that there's no obvious good reason to attempt this to begin with,
> did you consider simply throwing an exception instead? That's easier to
> explain and test.
That sounds reasonoable. It's probably uncommon enough to not matter
much but it could be surprising to get the metadata back to null
otherwise. Did you file an issue?
> *Playback state*
>
> The API no longer deals with audio focus, but playbackState seems to be a
> hint affecting what will actually get focus. I've requested some examples
> <https://github.com/WICG/mediasession/issues/175> and enough detail for a
> second implementer to achieve interoperability
> <https://github.com/WICG/mediasession/issues/177>.
We will add examples. Though, this is a feature request from Apple,
there are issues and PR with context if you want. The TL;DR is that some
websites might look like not playing but there UI is in playing mode
(for example, if they are seeking). The `playbackState allows the UA to
be aware of the state and overrides its own knowledge. There is a
similar API on Android and iOS.
> *Controls*
>
> setActionHandler avoids the problems that event listeners would have had,
> and feature detection is possible as unsupported actions would throw
> TypeError.
>
> The "previoustrack" and "nexttrack" actions make good sense, that's logic
> that has to be implemented by the page itself and there can be no default
> action given the lack of declarative playlists or similar.
>
> "seekback" and "seekforward" seem problematic as they don't include the
> number of seconds to seek. On iOS that number is included in the now
> playing controls
> <http://cdn.iphonehacks.com/wp-content/uploads/2016/06/ios-10-control-center-5.png>,
> so would it be possible to implement this on iOS? It seems to me that if
> seeking is under the page's control, which it has to be if using Web
> Audio,
> then in order to respect platform conventions the skip duration needs to
> be
> included. WDYT?
We never got this feedback from Apple so I would assume this is fine.
The API assumes there will be no UA default behaviour for these actions
so defining the time wouldn't make sense, the website should handle
this.
> For "play" and "pause", the spec says "It is RECOMMENDED for user agents
> to
> implement a default handler for the play and pause media session actions
> if
> none was provided for the active media session." I've filed an issue to
> flesh this out <https://github.com/WICG/mediasession/issues/178>. As
> actually implemented in Chromium, can pages register for for the "pause"
> action and ignore it, allowing playback to continue anyway? To ignore
> "play" I think should be possible, but I wonder if "pause" shouldn't have
> the semantics of "already-paused-now-you-may-react".
The specification allows a UA to force pause. At the moment, we've
decided to not do that in Chromium mostly because web pages can already
listen for the pause event and call `play()` again. We found a page that
had a bug that was doing just that. Force pausing in the pause action
would lead to timing issues. I do not think we should do
"already-paused-now-you-may-react" because we want these websites to
actually
> *Interoperability risk*
>
> Has there been any recent activity from other vendors, after the move to
> WICG and the changes that followed? I think the interoperability risk of
> this API is particularly high since it integrates with OS-level features
> which work quite differently on Android, iOS and other systems. Have you
> reached out to the relevant folks to say that you're now planning to ship
> this? (When not actively implementing, I wouldn't expect anyone to pay
> close attention.)
We've got good collaboration with Jer Noble from Apple. His last
contributions were on the `setActionHandler` just before the holidays.
As usual with Apple, we don't have launch timeline but if there was
anything that would prevent the API from being implemented by Apple on
iOS, I would expect them to express their concerns.