1391501 - Add an API to enable and disable media autoplay globally

Status: NEW

(WebExtensions :: General, enhancement, P5)

Description

[Loren Klingman]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170814073321

Steps to reproduce:

Since sometimes I want videos to autoplay and sometimes I want to scroll through pages without videos playing, but I don't want to open about:config all the time so  I've been using an extension to provide a button to do that in the toolbar (https://addons.mozilla.org/en-US/firefox/addon/autoplay-toggle/?src=search).

I am interested in contributing a web extension version of plugin, but there does not appear to be an API for turning autoplay on and off (mozilla config media.autoplay.enabled) which means it cannot be ported to work on FF57+.

Is there any possibility of adding the ability to turn autoplay on and off to the API?


Actual results:

I can't port the addon to web extensions.


Expected results:

I'd like to port the addon to web extensions using a media api.

Comment 1

[Caitlin Neiman [:caitmuenster]]

Hi Loren, this has been added to the agenda for the September 5 WebExtensions APIs triage meeting. Would you be able to join us? 

Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Next_Meeting

Agenda: https://docs.google.com/document/d/13gmYyN0qCjzV7YAsqGpbeeHr3al0yiWP7ayqKJPLS2w/edit#

Comment 2

[Loren Klingman]

Hi Caitlin, I'll join the meeting.  Is joining by phone and vidyo equivalent or is there one that would be better?

Comment 3

[Caitlin Neiman [:caitmuenster]]

Thanks, Loren! Phone and Vidyo are equivalent, but if you have low bandwidth, I would recommend calling in by phone.

Comment 4

[Caitlin Neiman [:caitmuenster]]

Approval pending Bob's investigation.

Comment 5

[Bob Silverberg [:bsilverberg]]

JW, it looks like you've done some work on the component that uses this preference, so I was wondering if you can comment on this. The proposal is to provide access to the `media.autoplay.enabled` preference to WebExtensions and I just wanted to make sure that that pref is something that we plan to keep around and isn't slated for deprecation. Could you please let me know, and also whether there are any issues you can think of with providing WebExtensions access to read and change this preference.

Comment 6

[JW Wang [:jwwang] [:jw_wang]]

I think this issue is more a WebExtensions issue than a media one.

1. We want to provide an ability for WebExtensions to change pref.
2. We don't want to enable WebExtensions to change arbitrary prefs to cause security issues.

We need to consult WebExtensions peers to know the best practice to give WebExtensions just enough privilege to change only one pref value.

Not sure who next to ask...

Comment 7

[Bob Silverberg [:bsilverberg]]

Thanks for the reply, JW. I am from the WebExtensions team and we do have an established way of granting access to an individual pref, so that's not an issue. I was looking for input from the media team about the impact of granting access to *this specific* preference. 

Can you confirm that it will do what we expect it to do (i.e., allow an extension to enable and disable autoplay of videos), and that it is a preference that we expect to be around for some time and is not slated for deprecation?

Comment 8

[JW Wang [:jwwang] [:jw_wang]]

I will leave the "media.autoplay.enabled" question to Alastor who has much experience in the autoplay feature.

Comment 9

[Alastor Wu [:alwu]]

I would like to postpone this discussion, because this pref is buggy now even it has been existed for release version for long time.

The main problem is, it isn't compatible with websites which use async function to start their video in user event callbacks. [1]

Therefore, I don't want to expose this pref when it still has lots problem, we could start discussion again after the problem is fixed.

Thanks!

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1231886#c52

Comment 10

[Bob Silverberg [:bsilverberg]]

Thanks for the detailed response, Alastor. It does sound like we should not expose this pref to WebExtensions until that bug is fixed, or it could lead to problems for users.

I'm going to mark this bug as approved, but blocked by bug 1231886.

Comment 11

[Stephan Sokolow]

Another significant question is whether it would be better to make the WE version tab-scoped, so extensions can be written which toggle it in response to tab navigation without any race conditions when other tabs are loading in parallel.

(eg. If I rapidly middle-click a bunch of links, I don't want it to be a crapshoot whether any specific tab will start playing the first time it gains focus.)

Comment 12

[Bob Silverberg [:bsilverberg]]

I doubt very much that we would do that, as right now we're just proposing to support toggling the pref via a WebExtension API, and the pref is global. This would allow an extension to turn it on or off. How exactly do you see this tab-scoped version you suggest working?

Comment 13

[Stephan Sokolow]

(In reply to Bob Silverberg [:bsilverberg] from comment #12)
> I doubt very much that we would do that, as right now we're just proposing
> to support toggling the pref via a WebExtension API, and the pref is global.
> This would allow an extension to turn it on or off. How exactly do you see
> this tab-scoped version you suggest working?

An extension would be able to register an event handler for some navigation-triggered event which is guaranteed to fire before autoplay or JavaScript execution and would then be able to set the autoplay policy for that tab.

(At minimum, based on the URL but, ideally, it should also be fired at a time which would allow it to make policy decisions based on the DOM, should the extension developer so choose.)

Essentially, allowing the implementation of something like NoScript or uMatrix, but for autoplay rather than JavaScript execution or loading various kinds of resources.

Comment 14

[Bob Silverberg [:bsilverberg]]

This sounds like it's moving far beyond the scope of the original bug, which was accepted by the design-decision-needed process. I'm going to re-title the bug to make it more explicit about what it is proposing, and was approved. 

Could you please open a separate bug for your proposal as it will need to be considered separately.

Comment 15

[Stephan Sokolow]

Understood and done.

See bug 1405827