Any changes to Firefox that would alter conversion of blobs in object URL src?

Support Software & Applications
1

I have some code I’ve been runnng for at least the past two years without issue. It uses Tcl as local server to browser and part of it fetches blob data from SQLite database using incremental blob, converts to an object URL and uses that as the source of an audio file. The largest blobs are about 40 MiB (about a 45 minute lecture).

Since the last update of Firefox, the largest blobs won’t play any longer. First, they would load, indicate that they were playing, but no timeupdate events ever fired and no sound and no errors thrown.

I thought I fixed that yesterday by adding a setTimeout around setting the source to the object URL. Sounds pretty stupid but it worked for awhile. Now, today, there is an error thrown that it cannot decode the blob to audio. There have been no changes to the audio blobs in the database; they are all mp3 and the exact same blobs I loaded two years ago–no changes to the database. It may be that the reason it stopped working today is that I opened a 42 MiB lecture.

If I run the code using a Chrome browser (Brave, for example) it all runs fine (without any setTimeout hack) for all the audio blobs I’ve tried that were failing in Firefox.

Any idea of what may have changed so that I can try to work around it?

Someone suggested not using an object url and to try the audio context API but that looks as though it is for something more complex than just playing an mp3 lecture of voice only; and the existing method has worked for two years and still works in Chrome; so must be a recent change in Firefox.

Thank you.

Could it have something to do with Firefox adjusting for this FFmpeg 8.1.2 vulnerability (CVE-2026-8461)?

I ask because the error in the console.log mentions FFmpeg.

I should’ve added also that it is not consistent. For example, after switching to Chrome and then back to Firefox, the same 42 MiB blob now plays. Although, earlier, I shutdown and restarted, and the error was there immediately.

2

Without understanding your code logic and implementation this would be very difficult to troubleshoot.

If it’s being temperamental I’d firstly go looking for network or connectivity issues, DNS, firewall, certificates etc.

As for specific Firefox changes, you’d likely get people with more idea on the Firefox forums.

3

Thanks. There are no network issues, etcetera, because it’s all local with Tcl as local server. The same exact code runs in chrome browser without issue. Seems very strange.

Placing a setTimeout around the handler to canplaythrough appears to have “fixed” it but only in that I can no longer trigger the issue. Another oddity is that placing the setTimeout around the last line that sets the source rather than in the handler, has the same result; and that makes no sense unless there is something before this code that needs time to complete but I cannot find anything.

  audio_elem.addEventListener(
     'canplaythrough',
     (event) => {
        setTimeout( () => {
           playList_load_cpt(
              mapObj,
              playObj.audio,
              trackId_node,
              footObj,
              event,
              currentTime,
              evt ? 1 : 0
           );
        }, 250)
     },
     {capture: false, once: true }
  );
  audio_elem.src = objectURL;

At times, Firefox throws an error stating it cannot convert the blob to audio and then a few minutes later can play the exact same blob.

Occasionally, this warning appears The mozAudioCaptured property will soon become unsupported. I don’t use that in my code but this site (about which I know nothing) mentions it and suggests it has to do with setMediaKeys and other sites state that “MediaKeys is a set of keys that an associated HTMLMediaElement can use for decryption of media data during playback.” None of this is used in my code but it may be in what Firefox runs to process it. Perhaps what appears synchronous is aysnchronous in the background?

Now that I learned about network tab in developer tools, I can obsereve that the largest blobs are being retrieved in about 175 ms; and that should be before the await of reading the response as blob, revoking oldest urls when exceed max total memory limit, creating the new object URL, and finally the await of play(). Thus, I can see the blob but won’t play in FF without that setTimeout.

At times, there is the error of DOMException: The fetching process for the media resource was aborted by the user agent at the user's request. But it appears only after a track won’t play as expected and then try to load another and first after removing the src attribute, execute audio.load() is the line that throws this error. It throws it for the track that was loaded but wouldn’t play. That makes no sense to me because once the src attribute is removed, there should be nothing to fetch and load() just resets it to empty. If I write out the element just before that line, it shows that it has no src to load.