1992172 - YouTube web version mobile/desktop not loading videos on Firefox v143.0.3 for Android

Status: VERIFIED FIXED

(Firefox for Android :: Media, defect)

Description

[lecasiv928]

Attachment: Screenshot_20251002-164343_01_01_01.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:143.0) Gecko/20100101 Firefox/143.0

Steps to reproduce:

1. Go to: www.youtube.com or any video link from YouTube. See step 3 for video link example.

2. A cookie options tab may appear, click on Accept all or Reject all.
   -The cookie tab may not disappear after clicking Accept all or Reject all. If this occurs try refreshing the tab or open a new tab with the YouTube homepage or video link.

3. If on YouTube default homepage, click on any video to play. Skip step 3 if already on the correct link as shown in the link example below.
   -link example after click on video: https://youtube.com/watch?v=TILjzuBGkRc

4. If video does not try to load automatically after tab is done loading, click on play icon.

Actual results:

Video does not load and shows error message after a few seconds.

The error message:

An error occurred. Please try again later. (Playback ID: REDACTED)
Learn More

Expected results:

Video playing as usual without error message.

Comment 1

[Daniel Holbert [:dholbert]]

Thanks for the bug report. I can repro on my Nexus 5 running Android 6, though not on another device with Android 16.

Would you mind sharing what your Android device is, and what its Android version is?

Comment 2

[Jim Mathies [:jimm]]

Reporter, are you only seeing this on youtube, or does it impact other video sites? Thanks!

Comment 3

[lecasiv928]

Thanks for the replies,

Reply to comment 1:
I cannot share the exact device, only that it is a different one. But I can share the OS version which is Android 6 as well.

Reply to comment 2:
Seems like the YouTube videoplayer only that shows this kind of error, may it be on the official site itself or embedded on another site. Other videoplayers seems to be working fine. Reddit and X/Twitter videoplayers for example do work.

Additional info added related to this report:
I also checked the webcompat link and it seems it might be my report, I apologize if it is a duplicate report, tried to create an account but lost the issue id. Not really familiar with reporting bugs.

In the webcompat report I stated that the new DNS option might have been the problem, but now I am convinced it is the new updated audio instead after checking the videoplayer debug.
From the debug info: "vemsg": "Error no decoder found for audio/opus".

Comment 4

[Daniel Holbert [:dholbert]]

Thanks -- I see a version of that message in my logcat diagnostic output as well:

10-02 16:06:27.767 17010  8083 I Gecko   : [Child 17010, MediaDecoderStateMachine #6] WARNING: Decoder=8c261580 Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - Error no decoder found for audio/opus: file /builds/worker/checkouts/gecko/dom/media/MediaDecoderStateMachineBase.cpp:168

Comment 5

[Daniel Holbert [:dholbert]]

Getting old builds to run is a bit fiddly on my device, but so far I've at least confirmed that Nightly 2025-01-01 does not reproduce the problem. So, this seems to be a regression (which I think matches the reporter's experience, which is that this is a regression in 143 in particular, as noted in first comment of the linked webcompat issue at least - "YouTube videos do not load after Firefox 143.0 latest update "))

One other notable factor here is that 143 happens to be the last version that supports Android 6, as noted at https://blog.mozilla.org/futurereleases/2025/09/15/raising-the-minimum-android-version-for-firefox/ . So: whatever fix we come up with here will likely wanted to be uplifted to a 143 dot-release.

Comment 6

[Daniel Holbert [:dholbert]]

Hmm, testing with mozregression, I'm getting "good" results even in the first few builds of Nightly 144.0a1 (before we dropped support and builds won't install on my Android 6 device). e.g. Nightly 144.0a1 2024-08-20 (built from m-c revision b4642edaad5a ) doesn't reproduce the issue for me.

That's confusing because I definitely reproduced the bug earlier today with a Nightly that was version 143 (I don't know what the datestamp was) which was installed & updated via the Play Store a while back.

So I'm suspicious that either there's some intermittency here, or maybe the mozregression builds I'm testing happen to be using a different configuration from the ones that I got from the play store...

Comment 7

[Daniel Holbert [:dholbert]]

Here's a profile of the issue happening in Firefox 143.0.3 (installed via Play Store), captured with "media" presets and logging enabled:
https://share.firefox.dev/3KvxjuQ

Comment 8

[Daniel Holbert [:dholbert]]

For comparison: here's a profile of the issue not-happening in Firefox Nightly 144.0a1 (installed via mozregression), captured with "media" presets and logging enabled:
https://share.firefox.dev/488CydG

Note that both this profile and the one from comment 7 have some logging for attempting to decode an Opus audio stream. But in the "bad" profile in comment 7, we get a marker of "type": "HTMLMediaElement:Error", wtth "errorMessage": "Error no decoder found for audio/opus". Whereas in the "good" profile linked here, we get no such error.

Comment 9

[Daniel Holbert [:dholbert]]

kinetik, I see you in commit logs having landed various updates to Opus - do you have any ideas about what might be involved here?

(note I don't have a regression range yet -- see comment 6 -- I haven't reproduced this at all with mozregression-installed builds yet, but it does repro with Firefox release 143.0.3 from the Play store at least, on my Android 6 device; and it reproduced with at least one play-store-installed Nightly 143 build with an unknown datestamp that I had earlier today but have since replaced in my mozregression testing.)

Comment 10

[Karl Tomlinson (:karlt)]

Perhaps John might have some ideas?

Comment 11

[Daniel Holbert [:dholbert]]

In attempting to bisect to identify a regression range, I found that this doesn't reproduce at all using our APKs from mozregression (i.e. APKs downloaded from archive.mozilla.org). Even if I use these APKs for 143.0.3, I don't hit the bug:
https://archive.mozilla.org/pub/fenix/releases/143.0.3/android/fenix-143.0.3-android/fenix-143.0.3.multi.android-universal.apk
https://archive.mozilla.org/pub/fenix/releases/143.0.3/android/fenix-143.0.3-android-armeabi-v7a/fenix-143.0.3.multi.android-armeabi-v7a.apk
...and yet 143.0.3 installed from the Play store does hit the bug.

However: tcampbell shared instructions for how to generate and install the same sort of collection-of-installer-packages that we use on the Play Store from archive.mozilla.org's "aab" files, and with that, I am able to reproduce the bug (using APKs generated locally from aab files downloaded from archive.mozilla.org).

That let me bisect to this regression range:
https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=ebf908f86af1&tochange=2c28b9cc7958

• Last known-good build (plays my test YouTube video just fine):
  https://archive.mozilla.org/pub/fenix/nightly/2025/07/2025-07-23-21-57-55-fenix-143.0a1-android/fenix-143.0a1.multi.android.aab
  Built from hg revision ebf908f86af1
• First known-bad build (hits the YouTube error described in this bug):
  https://archive.mozilla.org/pub/fenix/nightly/2025/07/2025-07-24-21-29-06-fenix-143.0a1-android/fenix-143.0a1.multi.android.aab
  Built from hg revision 2c28b9cc7958

Pushlog:
https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=ebf908f86af1&tochange=2c28b9cc7958

In that range, we have this commit which I'm tending to suspect as the regressor:
https://hg-edge.mozilla.org/mozilla-central/rev/e8aefd74680cef2bc0ddbd3967102308f06ce214

Bug 1867280 - Stop using legacy packaging for native libraries.

It's suspicious because: (a) it's about packaging and has several comments mentioning aab files, (b) it's about "legacy" Androids stuff, which seems relevant given that this bug is about Android 6, and (c) it was specifically removing a legacy thing, and it seems conceivable that maybe older Android versions might depend on legacy stuff. (And I wouldn't be surprised if we're using a native library for our audio decoding.)

RyanVM, could we try reverting that patch? If we can somehow generate .aab fenix builds for the 143 release repo before/after we hypothetically revert that patch, I'm happy to test them to confirm that it fixes the issue.

Comment 12

[Daniel Holbert [:dholbert]]

(I might be able to try building 143 locally, but I'm also not sure I've ever built fenix locally [I've built geckoview but not fenix] so I might run into some hiccups. Might see if I can outsource the task of generating the .aab files to someone else who's got a fenix build environment.)

Comment 13

[Daniel Holbert [:dholbert]]

So the patch to hypothetically backout here is:
https://hg-edge.mozilla.org/mozilla-central/rev/e8aefd74680c

That doesn't apply cleanly, though, particularly for the focus part, which is touching a packaging { ... } section that has since been removed in bug 1980520 , here: https://hg-edge.mozilla.org/mozilla-central/rev/b92e5f3238e0#l7.2

(Maybe we can just add back that "packaging { ... }" section, just as a wrapper for the snippet-to-be-brought-back-via-the-backout? not sure.)

The fenix part applies cleanly with fuzz, though, and that should be sufficient to test as a hypothetical fix here.

Comment 14

[Daniel Holbert [:dholbert]]

Attachment: patch to revert fenix parts of suspected regressor (probably incomplete; a full patch would need to revert the Focus bits, too)

Here's a patch to revert the fenix parts of Bug 1867280's patch.

Tomorrow I might seek help with generating .aab builds of Fenix release (v143) with & without this patch.

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1867280

Comment 16

[Adina Petridean QA [:apetridean]]

Attachment: Sony Xperia Z2 (Android 6.0.1)

Comment 17

[Adina Petridean QA [:apetridean]]

Comment on attachment 9518028 [details]
Sony Xperia Z2 (Android 6.0.1)

We were able to reproduce this issue only on the Sony Xperia Z2 (Android 6.0.1) running RC 143.0.3.

On the following devices, the issue could not be reproduced (tested on the latest Nightly, Beta 144.0b8, and RC 143.0.3):
Google Pixel 7 (Android 16)
Samsung Galaxy S23 Ultra (Android 15)
Samsung S24 Ultra (Android 15)
OnePlus 12R (Android 15)
Samsung Note 10 (Android 12)
Xiaomi 12T (Android 12)
Motorola Nexus 6 (Android 8)
LG Git (Android 9)
Sony Xperia Z5 (Android 7.1.1- only RC was verified)
OnePlus A3000 (Android 7.1.1 - only RC was verified)

Comment 18

[Ryan VanderMeulen [:RyanVM]]

Attachment: Bug 1992172 - Revert back to legacy packaging for app bundles.

Comment 19

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined: Broken YouTube playback on Android 6 devices
• Code covered by automated testing: no
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: STR per the incident channel and this bug.
• Risk associated with taking this patch: low
• Explanation of risk level: Just reverting us back to how we were previously building the app bundles. The main thing it'll lead to are significantly larger update sizes from Google Play as they can't optimize their delta updates as much with legacy packaging. But we can live with that for now since 144 drops Android <8 support anyway and that ships in less than 2 weeks.
• String changes made/needed: none
• Is Android affected?: yes

Comment 20

[Ryan VanderMeulen [:RyanVM]]

Try push: https://treeherder.mozilla.org/jobs?repo=try&revision=9df242b60bc672dabd167ea9f91852ff57d11daa

Polly was also able to reproduce this bug with local builds in the emulator and is working to test Focus now.

Comment 21

[Ryan VanderMeulen [:RyanVM]]

Added to the 143.0.4 release notes:

Fixed YouTube video playback issues on devices running older Android versions.

Also calling this wontfix for 144+ since this specific issue was only reproducible on Android 6.0 devices which won't be receiving updates past 143 as per the previous end-of-life announcement.
https://blog.mozilla.org/futurereleases/2025/09/15/raising-the-minimum-android-version-for-firefox/

Comment 22

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/2734d13b1379
https://hg.mozilla.org/releases/mozilla-release/rev/77b8325129d1

Comment 23

[Jan Brasna [:janbrasna]]

The reason why the opus audio should fail out of the blue just based on some bundle compression settings isn't immediately apparent, but there has been a note right after API 23 added support for reading compressed libs directly; quoting from: https://issuetracker.google.com/issues/37132359

"After this change, we saw that loading native libs was failing with UnsatisfiedLinkError on some Sony, LG and One Plus devices running Android M."

Reporter, any chance your device might fall into that group as well? (The only reproducible Android M occurrences confirmed were indeed on devices manufactured by Sony and LG in our case.)

(Feel free to add to the original webcompat report https://github.com/webcompat/web-bugs/issues/178456 if you can't add more details to this closed bug. Also v143.0.4 update has started rolling out, so please try updating your version to see if that fixes for you. Thanks for the report!)

Comment 24

[Adina Petridean QA [:apetridean]]

Attachment: 20251006_093622.mov

Verified as fixed on the Sony Xperia Z2 (Android 6.0.1) running RC 143.0.4 (installed from the play store and also from https://archive.mozilla.org/pub/fenix/candidates/143.0.4-candidates/build1/android/).

On the following devices, the issue is also not reproducible (tested on RC 143.0.4):
Google Pixel 7 (Android 16)
Samsung Galaxy S23 Ultra (Android 15)
OnePlus 12R (Android 15)
Samsung Note 10 (Android 12)
Motorola Nexus 6 (Android 8)