Fenix: FNX3-16402 ⁃ Toggle Media Autoplay

Created on 25 Jan 2019  ·  44Comments  ·  Source: mozilla-mobile/fenix

As a user, I want to be able to disable media autoplay on my browser, so I can save data and battery and have control over how I consume content.

UX mocks: https://app.abstract.com/share/cdba1651-670e-4412-8721-4d70ca025ffd?collectionLayerId=35603d5c-263c-4c70-b3fe-1ae23bd449c8&mode=design&sha=49143c0fafdf6c2d01f7c0b665c92a9fb7c0ebec

Acceptance Criteria

  • I can use a toggle in settings to allow/block media autoplay
  • When autoplay is disabled, audio and video content will not start playing unless I have initiated it.

Dependencies:

AC-by-Fenix E5 Media engverified ac gecko gv

Most helpful comment

@liuche would the remaining work be either all in Fenix or AC by Fenix and if so, can we add it to this sprint and take something else out?

All 44 comments

GV bug to add a setting to either allow or block autoplay videos:
https://bugzilla.mozilla.org/show_bug.cgi?id=1522324

Gecko already has this functionality. Adding a GV setting should be very easy.

For TRIAGE: This should probably go into milestone 3 backlog, please size first though and indicate dependencies (planned currently for milestone 3 or 4)

As per comment, we might pull this back into a Battery saving story after MVP, however it should land for MVP as an individual feature.

removed ux label -it's on our radar already as it's part of the Q3 plan

@sblatz I'd suggest we remove the second acceptance criteria "Block autoplay when on mobile" for now and add it as enhancement in a later story;

the options for autoplay are:

  • Allow audio and video
  • Block audio (default)
  • Block audio and video

@topotropic The GV API currently only allows to set it to ALLOW or BLOCK autoplay. Is that good enough for a first iteration or do we depend on separating this by media type (audio/video)?

I updated the strings and changed the logic slightly based on recommendation from content strategy.

The options are as follows:

  • Allow video and audio
  • Allow video and audio on WiFi only
  • Block audio
  • Block video and audio (Recommended)

https://share.goabstract.com/cdba1651-670e-4412-8721-4d70ca025ffd?collectionLayerId=35603d5c-263c-4c70-b3fe-1ae23bd449c8&mode=design

@topotropic making sure you also saw Sebastian's feedback:

@topotropic The GV API currently only allows to set it to ALLOW or BLOCK autoplay. Is that good enough for a first iteration or do we depend on separating this by media type (audio/video)?

We discussed this outside of this issue and found a way to support this. It requires additional AC work that we hadn't planned for initially. I'll file and link related AC issues.

Since this is a Must and it's waiting on two A-C tickets, I'm picking up this plus the A-C work to get this through the goalposts.

My investigation found that GeckoView currently lacks the necessary content/media permissions for blocking autoplay on a per request basis. We need additional features that exist on desktop.

If we want to land part of this with today's GeckoView, we can offer global allow/block of autoplay until the site permissions and exceptions become possible.

Here's the Bugzilla ticket for GV: https://bugzilla.mozilla.org/show_bug.cgi?id=1577596

This is in GV's Sept sprint.

@vesta, do we want an option with just Allow and block audioplay or wait for the GV implementation?

@topotropic let's go ahead with just allow and block for now. I have filed #5163 to track the future work.

Adding needs:gv label because this Fenix issue is waiting for GV bug https://bugzilla.mozilla.org/show_bug.cgi?id=1577596, which is expected to be fixed in September in GV 71 Nightly. TBD whether we can uplift to GV 70 Beta.

@cpeterso I think only the follow-up (#5163) will need that.

@cpeterso I think only the follow-up (#5163) will need that.

In that case, I'll remove the needs:gv label from this issue.

@vesta0 I'm moving this back to the feature backlog as it's no longer blocked. Please prioritize as necessary 😄

QA created this issue after testing the feature: https://github.com/mozilla-mobile/fenix/issues/5636

Currently, if I am listening to music in another app, say Vanilla Music, and scrolling through Twitter in Firefox Preview 2.1, my music playback is paused whenever I scroll onto a video. The video is muted until I hit the volume button on the video... But I still get the media notification that results in Vanilla Music pausing. Will this solve my issue?

@vesta0 what should we do with this ticket? It's currently behind a nightly/debug feature flag and has some outstanding GV bugs.

@sblatz if I remember correctly, we had the basic on/off hooks but were just missing the more granular options? If so, can we ship the basic on/off and create a new issue to track the rest?

@vesta0 basically there are some sites (as mentioned in #5636) that don't actually block autoplay. Because of that we put it behind a feature flag since we didn't want users thinking the feature didn't work properly. Would you prefer to ship it in 2.2 even though it won't work on some sites? Or should we wait for that GV patch to be fixed?

Thanks for the clarification @sblatz :) In that case let's wait for the GV patch to land.

@vesta0 I'm moving this to the feature backlog since it has a long-standing dependency.

This is in GV's November sprint.

This is in GV's November sprint.

@liuche - Which GV bug is that? Per-site autoplay permissions bug 1577596? That bug was kicked out of GV's November sprint because it is blocked by core Gecko work to be completed by the Gecko Media team: https://bugzilla.mozilla.org/show_bug.cgi?id=1593843

This should be ready from GeckoView in January - sizing is dependent on if the Gecko implementation is exposing a new setting and we need to do more in AC, or if nothing additional is needed.

The general autoplay setting does not work for twitter. I'm having this issue in Nightly https://github.com/mozilla-mobile/fenix/issues/255#issuecomment-539627186
Screenshot_20200101-161424_Firefox_Nightly

From what I understand this should not happen anymore, right? I don't care about per site settings, but about global ones including twitter.

Is my issue covered by this issue or should I report a new one?

Waiting on a bug to get fixed in GV before this can land, and then it can be picked up. Should land early January still.

Looks like the GV bugs are all closed, so this should be ready to work on. Unclear to me rn if this requires AC work, since there are already some APIs exposed.

@liuche would the remaining work be either all in Fenix or AC by Fenix and if so, can we add it to this sprint and take something else out?

Just want to confirm the strings on this. In the mocks we have the following:

image

but the rest of our options are phrased as "Blocked" or "Ask to Allow" which makes these preference options feel fragmented.

@topotropic

I started work on this, but it looks like we don't have access to the GeckoRuntimeSettings we need (even when I try to add them in AC, the right GV hooks are not exposed).

I have updated the GV bug with my questions: https://bugzilla.mozilla.org/show_bug.cgi?id=1593843#c25

Still some back and forth on this GV ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1593843#c27

For QA: we are going to narrow down the scope to just the following:

Remaining user stories will be addressed later on: #8017

Screenshot_20200131-115135

@sblatz based on our conversation I am moving this issue to eng:qa:needed

I believe we still need to remove the feature flag here, so I don't think QA will be able to verify just yet. Making this visible is on the top of my list :)

Thanks for clarifying that @sblatz :)

@vesta0 did you end up making a follow up ticket for these other features?

Yes, here it is: #8017

QA can confirm that on the latest Nightly from 2/11, the Autoplay has 2 options:

  • Video and audio blocked (Recommended) - set by default,
  • Video and audio allowed.

Verified with Google Pixel (Android 10), and OnePlus (Android 9).
However, issue #5636 is still reproducible, so I'm only going to remove the qa:needed label.

I'm going to close this ticket and let's address #5636 as a follow up 😄

Was this page helpful?
0 / 5 - 0 ratings