{"action":"created","issue":{"url":"https://api.github.com/repos/whatwg/mediasession/issues/41","labels_url":"https://api.github.com/repos/whatwg/mediasession/issues/41/labels{/name}","comments_url":"https://api.github.com/repos/whatwg/mediasession/issues/41/comments","events_url":"https://api.github.com/repos/whatwg/mediasession/issues/41/events","html_url":"https://github.com/whatwg/mediasession/issues/41","id":78528763,"number":41,"title":"What to do with the default media handling 'magic' in mobile browsers?","user":{"login":"richtr","id":497699,"avatar_url":"https://avatars.githubusercontent.com/u/497699?v=3","gravatar_id":"","url":"https://api.github.com/users/richtr","html_url":"https://github.com/richtr","followers_url":"https://api.github.com/users/richtr/followers","following_url":"https://api.github.com/users/richtr/following{/other_user}","gists_url":"https://api.github.com/users/richtr/gists{/gist_id}","starred_url":"https://api.github.com/users/richtr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/richtr/subscriptions","organizations_url":"https://api.github.com/users/richtr/orgs","repos_url":"https://api.github.com/users/richtr/repos","events_url":"https://api.github.com/users/richtr/events{/privacy}","received_events_url":"https://api.github.com/users/richtr/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-05-20T13:32:40Z","updated_at":"2015-05-21T08:58:29Z","closed_at":null,"body":"From the [spec](https://mediasession.spec.whatwg.org/#introduction):\r\n\r\n> When playing media on the web, developers are currently forced to adopt a single default platform modality for playing all media content. On the other hand, native applications can access much richer media integration options with an underlying platform. On mobile devices, native application developers can request many different forms of media integration with the platform to obtain access to headphone buttons, lock screens and notification areas as needed. On desktop devices, native applications have access to keyboard media key events. Native application developers can specify the conditions in which media content should pause or duck on audio interruptions (i.e. pause or lower the volume for the duration of an interruption), continue playing out when application focus is lost or the device screen is switched off and interface with internal and external remote controllers.\r\n\r\nIf media sessions allow web developers to opt-in to custom platform-level media behavior on different platforms why do we insist on enforcing strict, arbitrary platform-level integration in the case that web media content has not opted-in to that?\r\n\r\nCurrently on mobile devices, by default, &lt;audio> will continue playing out when the web browser is backgrounded and/or the device's screen is switched off. It may provide notification area controls and allow users to play and pause the audio content from the notification area. Clicking on the notification may bring the user back to the browser and, ideally, bring the tab making the noise to the foreground. It may display audio metadata on the homescreen, obtained from either the &lt;audio> element or document metadata (such as document title and favicon). It may only allow only one media element to play out at a time or mix multiple media elements to play out at the same time. It may automatically pause &lt;video> when the browser is backgrounded. ...or it may not do any or some of these things depending on which browser you try.\r\n\r\nAll of this behavior is a.) inconsistently provided across different web browsers, b.) completely magic in that it cannot be observed or controlled by web applications and c.) must be opted-out of (instead of having to opt-in to it in the first place) by web developers through the introduction of [media sessions](https://mediasession.spec.whatwg.org/#media-sessions).\r\n\r\nIn line with the principles of the [extensible web manifesto](https://extensiblewebmanifesto.org) we must try to explain or remove this auto-magic behavior for default media handling by specifying how '[default](https://mediasession.spec.whatwg.org/#default-media-state)' media playback should perform consistently across different web browsers and devices.\r\n\r\nSo what should we do? Describe the current magic of default media handling somehow? Choose a single sensible, consistent modality for default media handling on mobile devices (e.g. by default let's choose to treat all media as  '[ambient](https://mediasession.spec.whatwg.org/#ambient-media-state)' content)? Or should we just leave the magic of default media handling alone and not try to explain it in programmatic terms and continue to leave this up to implementors to decide what platform-level inter-operation and integration to provide by default for media content?"},"comment":{"url":"https://api.github.com/repos/whatwg/mediasession/issues/comments/104186685","html_url":"https://github.com/whatwg/mediasession/issues/41#issuecomment-104186685","issue_url":"https://api.github.com/repos/whatwg/mediasession/issues/41","id":104186685,"user":{"login":"foolip","id":498917,"avatar_url":"https://avatars.githubusercontent.com/u/498917?v=3","gravatar_id":"","url":"https://api.github.com/users/foolip","html_url":"https://github.com/foolip","followers_url":"https://api.github.com/users/foolip/followers","following_url":"https://api.github.com/users/foolip/following{/other_user}","gists_url":"https://api.github.com/users/foolip/gists{/gist_id}","starred_url":"https://api.github.com/users/foolip/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/foolip/subscriptions","organizations_url":"https://api.github.com/users/foolip/orgs","repos_url":"https://api.github.com/users/foolip/repos","events_url":"https://api.github.com/users/foolip/events{/privacy}","received_events_url":"https://api.github.com/users/foolip/received_events","type":"User","site_admin":false},"created_at":"2015-05-21T08:58:29Z","updated_at":"2015-05-21T08:58:29Z","body":"A variation of option 2a I think is worth considering is to forget about the extra brokering layer, so that cross-origin iframes within a tab simply compete with each other for audio focus. In the case of YouTube or SoundCloud embedded iframes, this is the likely end result anyway, as such sites would need to create a `MediaSession` of kind \"content\" in order to customize the lock screen and notification UI."}}