autoplay restrictions only apply to Android; even for data saver. +mlamouri and +ojan who have looking at this most recently. In the end I think this is a Data Saver product decision, but need a longer discussion.

Stopping autoplay for desktop just for data savera is like to break a lot of sites; e.g., ad preroll will never disappear because it never plays and thus never ends.

As Dale said, implementing this on desktop will break a lot of unintended scenarios and users won't know why (for example: Pandora may just stop playing every time it gets to a mid-song ad). We are working hard on a new proposal for autoplay on desktop and mobile. Instead of taking an immediate action on this bug, let me add this to the list of considerations to make sure we factor it in. We have a KR to have a signed off plan by the end of quarter. Assigning this bug to me.

Sounds good, thanks Jon. I didn't realize the autoplay behavior for Data Saver was restricted to Android.

Just a thought - on desktop, maybe we could  have a UI notification (e.g., from the Data Saver extension itself) if autoplay was disabled on a given page, so the user knows and could disable that behavior. This is hard to do on mobile but easier on desktop.

Thank you for the suggestion. Yes, a per-page notification of some sort is one of the options we could explore. In most circumstances, it would be far too noisy because of the pervasive use of autoplay. However, given that the user has explicitly installed an extension, it may be a more acceptable option. 

FWIW, even on mobile, we are considering moving away from the autoplay restrictions when Data Saver is on. We need to find something better. The relation between the two features has taken a few users and developers off guard and couldn't understand why autoplay wasn't working or why a page was broken.

I agree that we need to find something better, but we also need to be very careful removing this feature until we are convinced we actually have that solution. If you have examples (bugs, complaints, anecdotes) of where this has caused a problem on mobile, I would love to hear them to make sure we factor them into the plan.

Agreed with Jon that lifting this restriction will require a great deal of careful thought. I recommend we get together to discuss before we get too far along in that plan.

dahlke@, I don't have a list of bugs because they basically all got closed because it was "working as intended".

In addition of the users/developers feedback, the issue with Data Saver is that it's actually enabling a proxy. This is presented as compressing data to the user, not as disabling some features. What we need instead is a generic toggle that says that some feature such as preload/prerender/autoplay will be disabled. I think there is even a point that can be made that disabling autoplay muted on data saver is harmful to the user because websites could switch to a GIF instead of a muted video, thus consuming significantly more bandwidth because the GIF can't be as efficient as a video that went through the data saver proxy.

Anyway, looking into this is part of the autoplay OKRs this quarter.

In practice, we have taken a far more liberal view of the user's intent with data saver mode and have disabled features, including downloading images and using preview mode, to ensure that we can save the user as much data as possible. I would say that disabling autoplay is in the same spirit and probably causes fewer issues than those other interventions. The difference here is that we don't provide any escape hatch for autoplay whereas we do for the other features. 

To be clear, I am not saying that removing autoplay blocking shouldn't be on the table, just that we want to consider all implications and make sure we include the EM and Flywheel teams as part of the discussion. I will take the AI to make sure that happens.