Using Media Session API in cross-origin setup
Reported by
teodorma...@gmail.com,
Apr 10 2017
|
|||
Issue descriptionSteps to reproduce the problem: Let's suppose we have a domain name, which may or may not be under our control, where the audio/video player is hosted. We also control a different domain name where we will host the players in iframes. The player code may or may not use Media Session API. We want to use one or more of these players on our page. If we run the attached snippet, the browser will create a plain Media Notification, with the visible indication of the metadata source set to 127.0.0.1 (or other parent domain name, where the snippet is hosted). Current version of the specs says: "It is recommended that the user agent offers a way to find the origin or clearly expose the origin of the website from which the metadata are coming from." @ https://wicg.github.io/mediasession/#user-interface-guidelines The Play/Pause button on the Media Notification will affect the iframe player, bypassing the Media Sessions `play` handler set by parent frame. So the Media Notification is not displaying the right source of the metadata, since that 'data' can only be filled in by the iframe's code. Nothing on that notification 'links' to the parent frame's code. There are two distinct problems here: displaying the metadata source and handling the notification interactions. What is the expected behavior? What went wrong? One use case for intercepting the interactions by the parent frame is when there are multiple iframe players on the page (maybe each player can only play one media or we have players from distinct domains). Using the action buttons on the Notification, the parent can control which media source to play. This can be made possible with 'bubbling' events, which go from parent to child frame handlers. This event may allow preventing the default action. For example, the parent takes care of selecting the next track to play, so iframe's "next track" mechanism is suppressed. One use case for overwriting the metadata is for extending the current capabilities of the iframe player. For example providing the next/previous option when the iframe player can only play one track and needs src update to load another track. The parent frame can then set the "album" to the title of the current playlist which the parent is playing. Implementing this can become problematic when both iframe and parent (one or multiple), all set the Media Metadata. When creating the MediaMetadata object we can specify the rules for overwriting the metadata (ex. overwrite all [parent supplies entire object], extend keys [attributes not set by child are taken from parent object], etc). Or we can expose a flag that will indicate whenever Media Metadata was already set by a different origin/frame and let the parent decide if it needs to be overwritten. Did this work before? No Does this work in other browsers? Yes Chrome version: 57.0.2987.132 Channel: stable OS Version: 4.2.1 Flash Version:
,
Apr 10 2017
Thanks for filing the issue. We had this in mind when designing the API. For achieving this goal we need some more complex mechanisms (such as permission delegation) to tackle the trust and race condition between the embedder and iframe. It was a bit overkill to include in the spec V1, but definitely worth consideration to make the spec more powerful. I've filed https://github.com/WICG/mediasession/issues/194 to track on the spec.
,
Apr 10 2017
|
|||
►
Sign in to add a comment |
|||
Comment 1 by phistuck@chromium.org
, Apr 10 2017Components: Internals>Media>Session