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

[Bug] Video Playback Errors and GIF playback errors in Firefox for Android #8503

Closed
st3fan opened this issue Feb 18, 2020 · 15 comments
Closed
Labels
🐞 bug Crashes, Something isn't working, .. eng:qa:verified QA Verified eng:ready Ready for engineering Feature:Media

Comments

@st3fan
Copy link
Contributor

st3fan commented Feb 18, 2020

https://bugzilla.mozilla.org/show_bug.cgi?id=1613446

More details in the Bugzilla bug

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Safari/605.1.15

Steps to reproduce:

Try to play any video or GIF on any web page. This happens on all of the latest Firefox releases, be it stable, beta, or preview editions. I am on Android 10 on a Samsung Note10+ phone. No add-ons are enabled. Clearing cache/data does not help. Reinstalling app does not help. It is not a connection problem, this happens on both WiFi and 5G data connection.
See video of this happening here:
https://www.youtube.com/watch?v=TXY2ukA6cRg

Actual results:

Videos end with all sorts of error messages and don't play the next video in the queue, or "glitch out" and flash randomly black colors. GIFs do not loop as they are supposed to, or experience the same issues as the videos.
Please see the video of this happening here:
https://www.youtube.com/watch?v=TXY2ukA6cRg

Expected results:

Videos should play with no error messages, and start the next video in the playlist. GIFs should loop.

┆Issue is synchronized with this Jira Task

@st3fan st3fan added the 🐞 bug Crashes, Something isn't working, .. label Feb 18, 2020
@github-actions github-actions bot added the needs:triage Issue needs triage label Feb 18, 2020
@Photogad

This comment has been minimized.

@liuche
Copy link
Contributor

liuche commented Feb 20, 2020

Also seeing this on https://blog.elementary.io/appcenter-spotlight-planner/
at section with "look at these cute animations"

Gif doesn't play (and is frozen) and when backgrounding the app, the gif turns black.

Screenshot_20200219-180121

@Amejia481
Copy link
Contributor

This will be addressed on mozilla-mobile/android-components#5953 and #8618

@severinrudie
Copy link
Contributor

@vesta0 we can allow/block audible autoplay (affects video and audio that is unmuted), and inaudible autoplay (affects muted videos). Note that many things that look like GIFs are actually muted videos, and will be blocked under the second setting (also true on desktop).

Right now, we only expose this to users:
Screen Shot 2020-02-26 at 3 02 09 PM

Should we:
1 - always allow inaudible autoplay: this means muted videos would always play regardless of the setting.

2 - have inaudible autoplay follow audible autoplay's setting: this means we would unexpectedly block some things that look like GIFs (example).

3 - expose a third “Block audio” option to users, similar to desktop: this is already on the roadmap, but would need a new String.

@vesta0
Copy link
Collaborator

vesta0 commented Feb 28, 2020

Hey @baron-severin I assume we don't have a way of differentiating between video files and GIFs or animations which makes sense, and also it seems like "block video autoplay" doesn't just stio the GIF from being animated but blocks it entirely. If that's all true, then I recommend option 3 (adding the "block audio only" as default). Although I thought we needed GV work for that and that's why it was scoped out initially - is that no longer the case?

If that works, then we can use the original mocks for the string and ask Jeff to see if we can uplift it for localization for April?

@severinrudie
Copy link
Contributor

Although I thought we needed GV work for that and that's why it was scoped out initially - is that no longer the case?

That API was recently exposed, so we should be good to go.

If that works, then we can use the original mocks for the string and ask Jeff to see if we can uplift it for localization for April?

Sounds good, I'll get started on it.

severinrudie added a commit to severinrudie/fenix that referenced this issue Mar 2, 2020
severinrudie added a commit to severinrudie/fenix that referenced this issue Mar 2, 2020
mozilla-l10n-automation-bot pushed a commit to mozilla-l10n-automation-bot/android-l10n that referenced this issue Mar 2, 2020
mozilla-l10n-automation-bot pushed a commit to mozilla-l10n-automation-bot/android-l10n that referenced this issue Mar 2, 2020
mozilla-l10n-automation-bot pushed a commit to mozilla-l10n-automation-bot/android-l10n that referenced this issue Mar 3, 2020
mozilla-l10n-automation-bot pushed a commit to mozilla-l10n-automation-bot/android-l10n that referenced this issue Mar 3, 2020
mozilla-l10n-automation-bot pushed a commit to mozilla-l10n-automation-bot/android-l10n that referenced this issue Mar 3, 2020
mozilla-l10n-automation-bot pushed a commit to mozilla-l10n-automation-bot/android-l10n that referenced this issue Mar 3, 2020
mozilla-l10n-automation-bot pushed a commit to mozilla-l10n-automation-bot/android-l10n that referenced this issue Mar 3, 2020
mozilla-l10n-automation-bot pushed a commit to mozilla-l10n-automation-bot/android-l10n that referenced this issue Mar 3, 2020
mozilla-l10n-automation-bot pushed a commit to mozilla-l10n-automation-bot/android-l10n that referenced this issue Mar 3, 2020
mozilla-l10n-automation-bot pushed a commit to mozilla-l10n-automation-bot/android-l10n that referenced this issue Mar 3, 2020
mozilla-l10n-automation-bot pushed a commit to mozilla-l10n-automation-bot/android-l10n that referenced this issue Mar 3, 2020
mozilla-l10n-automation-bot pushed a commit to mozilla-l10n-automation-bot/android-l10n that referenced this issue Mar 3, 2020
mozilla-l10n-automation-bot pushed a commit to mozilla-l10n-automation-bot/android-l10n that referenced this issue Mar 3, 2020
mozilla-l10n-automation-bot pushed a commit to mozilla-l10n-automation-bot/android-l10n that referenced this issue Mar 3, 2020
@liuche liuche added eng:ready Ready for engineering and removed needs:triage Issue needs triage labels Mar 27, 2020
@liuche
Copy link
Contributor

liuche commented Mar 27, 2020

I think these commits are related to pre-work for this bug, but now that that PR is landed, this should be ready to work on. May require exposing some APIs from GV through AC.

@Amejia481 do you know if this is ready to be worked on? I see the AC issues you linked earlier are closed, but this still seems to be happening.

@Amejia481
Copy link
Contributor

This is a related pr that needs review #9372

@liuche liuche removed the eng:ready Ready for engineering label Mar 27, 2020
@ekager ekager added the eng:ready Ready for engineering label Apr 11, 2020
@ekager
Copy link
Contributor

ekager commented Apr 11, 2020

Sounds like the prework is done and merged so labeling as eng:ready again

@ekager
Copy link
Contributor

ekager commented May 8, 2020

Hey @baron-severin I assume we don't have a way of differentiating between video files and GIFs or animations which makes sense, and also it seems like "block video autoplay" doesn't just stio the GIF from being animated but blocks it entirely. If that's all true, then I recommend option 3 (adding the "block audio only" as default). Although I thought we needed GV work for that and that's why it was scoped out initially - is that no longer the case?

If that works, then we can use the original mocks for the string and ask Jeff to see if we can uplift it for localization for April?

cc @vesta0 there have been some updates here.

It looks like gifs are distinguishable if they are truly gifs and not just muted videos - ie on giphy.com gifs are now being played with default "block audio and video" option.

With that being said, should we still revisit the current default state? Is "block audio and video" as the default still desired now that we have added the new "block audio only" option and we can distinguish between audible or inaudible video? To test the two different behaviors go to googlechrome.github.io/samples/muted-autoplay and change the Fenix setting between "block audio and video" and "block audio only" (and refresh the page). Both videos are blocked with the default "block audio and video", but the muted video is allowed with "block audio only". It looks like Chrome Android and Firefox Desktop allows the first inaudible video to autoplay.

@vesta0
Copy link
Collaborator

vesta0 commented May 13, 2020

Thanks @ekager for the detailed description and example :)

Since gifs will play with the "block audio and video" option then I think our default should be "block audio and video" due to its impact on pageload performance + potential data saving.

Although, it looks to me like "block audio and video" is already our default and perhaps we never changed it to "block audio only" ?

@ekager
Copy link
Contributor

ekager commented May 13, 2020

Yes, exactly, we never actually changed the default. If we want to keep it as "block audio and video" then I think we can close this ticket since the comment 0 issue has been resolved AFAICT.

@vesta0 vesta0 added the eng:qa:needed QA Needed label May 13, 2020
@vesta0
Copy link
Collaborator

vesta0 commented May 13, 2020

Please QA the comment 0 issue and close this ticket if verified.

@yoasif
Copy link
Contributor

yoasif commented May 14, 2020

Not sure if this is the same issue, but the video on this page is not playing if I set Fenix to request the desktop site: https://i.imgur.com/5dS6Ni4.gifv

Should I open a new issue?

@lobontiumira
Copy link

lobontiumira commented May 27, 2020

Verified as fixed - videos and GIFs play with no error messages.
Tested on the 5/27 Nightly build with Sony Xperia Z5 Premium (Android 7.1.1), Google Pixel (Android 10), and Samsung Galaxy Note 8 (Android 9), on the following pages: reddit.com, cnn.com, giphy.com, twitter.com, youtube.com.

  • Note: "Block audio and video" is selected by default.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
🐞 bug Crashes, Something isn't working, .. eng:qa:verified QA Verified eng:ready Ready for engineering Feature:Media
Projects
None yet
Development

No branches or pull requests

10 participants