Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Give extensions easy access to MediaSession #522

Open
gregorypappas opened this issue Jan 16, 2024 · 2 comments
Open

Proposal: Give extensions easy access to MediaSession #522

gregorypappas opened this issue Jan 16, 2024 · 2 comments
Labels
neutral: chrome Not opposed or supportive from Chrome neutral: firefox Not opposed or supportive from Firefox neutral: safari Not opposed or supportive from Safari

Comments

@gregorypappas
Copy link
Member

I've been prototyping a browser extension that adds play/pause buttons to the tab context menu. A problem I've run into is that there's no good way to interact with a page's MediaSession from the background. Currently, I've worked around this by using a content script and message passing. This is not good for performance and requires the scary 'Access your data for all websites' permission, which is not ideal for Manifest v3.

It'd be neat if the background service worker could:

  • Activate action handlers like play/pause
  • Access metadata and playbackState
  • Listen to events for when playback state is updated, metadata is updated, supported action handlers are updated, etc.

With these capabilities, lots of cool extensions could be made. I'm not sure what a concrete API design would look like at this point.

@oliverdunk
Copy link
Member

This seems like an interesting idea to me. It does feel like it would require a fairly large API surface though and with that there would be an implementation cost which I suspect would make it hard to prioritise, at least on the Chrome side.

I think it would be good to find either a browser vendor willing to prioritise this or someone willing to work on an implementation before we discuss in too much detail.

@Rob--W Rob--W added neutral: chrome Not opposed or supportive from Chrome neutral: safari Not opposed or supportive from Safari neutral: firefox Not opposed or supportive from Firefox and removed needs-triage labels Feb 15, 2024
@Rob--W
Copy link
Member

Rob--W commented Feb 15, 2024

Discussed in today's meeting - a concrete API proposal plus willingness to provide a patch is necessary for this to move forward.

For the record, the Firefox side of this request is tracked at https://bugzilla.mozilla.org/show_bug.cgi?id=1872636

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
neutral: chrome Not opposed or supportive from Chrome neutral: firefox Not opposed or supportive from Firefox neutral: safari Not opposed or supportive from Safari
Projects
None yet
Development

No branches or pull requests

3 participants