Skip to content
This repository has been archived by the owner on Feb 20, 2023. It is now read-only.

Restore autoplay on muted video by default or ask for user consent. #16557

Closed
rsepierre opened this issue Nov 13, 2020 · 8 comments
Closed

Restore autoplay on muted video by default or ask for user consent. #16557

rsepierre opened this issue Nov 13, 2020 · 8 comments
Assignees
Labels
eng:qa:verified QA Verified Feature:SitePermissions S2 Major Functionality/product severely impaired and a satisfactory workaround doesn't exist

Comments

@rsepierre
Copy link

rsepierre commented Nov 13, 2020

What is the user problem or growth opportunity you want to see solved?

Summary : The current Firefox for android state is by default to block video autoplay as a "global settings" (for all websites).
It is then most likely blocked for most if not all users.

Justification :
The last patch note signaling the an update to the "autoplay" feature dates back to firefox for android version 66.
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/66
This update states that any media element with audio will be blocked. But this is not the current state of the feature as all media will be blocked by default whether they have an audio track, are muted, have the volume set to 0 or not.

Every piece of mozilla's documentation states that "muted media element" should auto-play.
Which might signify that the current state is either an oversight or a bug ?
Although it seems to be presented as a feature hidden in Menu > Settings > Site Permissions > Automatically read media elements

List of problems :

  • The setting is set to "block audio and video" by default
  • Mozilla's and MDN and patch notes are not up to date with the current state of the feature.
  • At no time during the installation the user is prompted to opt-in or out of the feature.
  • GIF's (1987's technology) are still enabled in firefox, making any "storage, performance and data" justification for blocking autoplay being "a feature" counterproductive (encouraging developpers to use old but working technologies for animated content).
  • WebGL and canvas (modern technologies) which can be animated by default can be - if used poorly - very performance, battery, data or visually demanding. Which makes any "behavioral" or "performance" justifications to blocking video autoplay also inconsistent with those features not being blocked by default.
  • Web developpers can not ask for user consent to use the feature on their website.
  • Users can not set "granular" consent (add a non-invasive website to a whitelist and keep autoplay blocked on more intrusive websites)
  • The setting is very much hidden and users might not even know it is disabled or how to enable it.

How do you know that this problem exists today? Why is this important?

The consequences :
The current status is essentially killing the modern html5 autoplay feature accross the whole internet for any developper who cares about supporting fenix OR dooms the browser itself because developers won't bother to support it. This is especially true as all documentation, suggest that firefox perfectly support and enables autoplay (like MDN and caniuse.com).

Exemple of a website being worse because of it :
Giphy.com (arguably the biggest gif sharing website) is usualy using ".wepb" or ".mp4" video instead of GIFs. For firefox they have a fallback to use true GIF format. Making the website 10 to 100 times less data efficient on fenix than on other browsers.

Usecases in favor of supporting video autoplay :
Not all video on the web is used as a "film" with video, audio, a start, an end and ment to be watched in full.
Just as canvas and webgl the "video" element can be used as a "animated thing". While blocking "autoplay" may not be a problem, and could even be a feature for the most traditional use of videos or ads. By blocking autoplay by default unlike any competitor and by not providing any way for developpers to prompt users to consent to enable the feature on a website by website base, the case could be made that it is almost equivalent to removing the feature for all firefox mobile users altogether. If Firefox for android was to grow it's market share, developpers might stop using the autoplay feature accross the web, either abandonning their original idea or relying on less optimized technologies.

More on the subject:
Google's article on the consequences of disabling autoplay and why is it important for developpers to have accurate data on if they can use the feature or not :
https://developers.google.com/web/updates/2016/07/autoplay

Dev.com's article on important benefits of the feature over older technologies (not blocked by firefox) :
https://web.dev/replace-gifs-with-videos/

My pull request to MDN's browser compatibility data ( featured on caniuse.com - autoplay ) to add a note to notify developpers that firefox mobile users will most likely block autoplay element :
mdn/browser-compat-data#7356

Tested on : Firefox for android 82.1.3 (Build #2015774643)

Any solutions ?

Feature request:
Here is multiple ideas / ways we could improve the situation.

  • Either rollback and support muted video's autoplay setting by default.
  • Add a way for developpers to ask for user consent to autoplay videos on a site to site basis.
  • Warns or add visual clue to the users that he is missing the full experience of the animated website

Alternatively

  • If the consensus is that video autoplay should be kept as muted by default (which has some minor benefits, primarily intrusive ads, battery, performance and data consumption) then animated GIF's should be blocked by default. And the question should also be asked for canvases, webgl and other features which might present similar caracteristics.

Who will benefit from it?

Developpers, users, mozilla

┆Issue is synchronized with this Jira Task

@github-actions github-actions bot added the needs:triage Issue needs triage label Nov 13, 2020
@Amejia481
Copy link
Contributor

Thanks for filing this ticket @rsepierre, we are working on #11325 to allow users to indicate their autoplay preference per site, and also addressing other related issues #8987

@rsepierre
Copy link
Author

rsepierre commented Nov 13, 2020

Hi @Amejia481 a'd thank you for your answer !
I am wondering.

Say that site based authorisations and issues are fixed for fenix to have consistent behavior. Is the intent still to purposefuly block muted/silent video from autoplaying by default ? And if so, would there be any way the user know he is missing something ? (and thus maybe he would think by himself about whitelisting the website) and/or for the developper to prompt the user for consent ? (Just as you would for using the webcam or other APIs).

As much as I think you should have the user's consent to impose something to the user (say autoplaying a video)
I think you should also need consent to strip out functionality and content away and offer the opportunity to provide conscious choice if fenix is to alter the developper's intent (more over as is it following MDN's and most common guidelines)

@kbrosnan
Copy link
Contributor

Closing as a duplicate of #11027

@abodea abodea removed the needs:triage Issue needs triage label Nov 17, 2020
@Amejia481 Amejia481 reopened this Nov 17, 2020
@Amejia481
Copy link
Contributor

Let's revise as the issue is more about web compatibility.

@Amejia481 Amejia481 self-assigned this Nov 17, 2020
@Amejia481
Copy link
Contributor

@rsepierre I agree with you, we should change the default setting to just block audio content by default as we are doing in Firefox desktop, bellow the default setting on it.

image

We are working on #11325 to allow users to indicate their autoplay preference per site, also be aware that we have a pending issue for autoplay that depends on this geckoview bug https://bugzilla.mozilla.org/show_bug.cgi?id=1647779

Amejia481 added a commit to Amejia481/fenix that referenced this issue Nov 18, 2020
@Amejia481
Copy link
Contributor

Amejia481 commented Nov 18, 2020

@rsepierre we are addressing the change here, in case you want to give some feedback :)

Amejia481 added a commit to Amejia481/fenix that referenced this issue Nov 18, 2020
Amejia481 added a commit to Amejia481/fenix that referenced this issue Nov 19, 2020
Amejia481 added a commit to Amejia481/fenix that referenced this issue Nov 19, 2020
Amejia481 added a commit to Amejia481/fenix that referenced this issue Nov 19, 2020
@Amejia481 Amejia481 added the S2 Major Functionality/product severely impaired and a satisfactory workaround doesn't exist label Dec 2, 2020
@wisniewskit
Copy link

Just FYI, this is of course causing webcompat reports, for instance https://webcompat.com/issues/61221

Amejia481 added a commit to Amejia481/fenix that referenced this issue Mar 5, 2021
Amejia481 added a commit to Amejia481/fenix that referenced this issue Mar 5, 2021
Amejia481 added a commit to Amejia481/fenix that referenced this issue Mar 5, 2021
Amejia481 added a commit to Amejia481/fenix that referenced this issue Mar 6, 2021
Amejia481 added a commit to Amejia481/fenix that referenced this issue Mar 10, 2021
@lobontiumira
Copy link

Verified on the Beta 89.0.0-beta.1 Build, and 4/22 Nightly with Samsung Galaxy Note 8 (Android 9), and Google Pixel (Android 10), on the reparofilms.com page, and on the bristolprintatelier.com, and here are my findings:

  • If the user allows audio & video from Settings - Site permissions - Autoplay, both pages start their videos, on mute.

  • If the user does not allow audio & video from Settings - Site permissions - Auoplay, the videos don't start, the blue dot is displayed on the padlock icon. The user can select from tapping on it to "Allow audio and video", then the video starts on mute. Then both pages are set as exceptions on Site permissions page in Fenix.

@lobontiumira lobontiumira added the eng:qa:verified QA Verified label Apr 22, 2021
pkirakosyan pushed a commit to gexsi/user-agent-android that referenced this issue Aug 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
eng:qa:verified QA Verified Feature:SitePermissions S2 Major Functionality/product severely impaired and a satisfactory workaround doesn't exist
Projects
None yet
Development

No branches or pull requests

7 participants