🏔️ ">The Two-Year-Old Firefox ARM64 Video Bug - FratelloBigioThe Two-Year-Old Firefox ARM64 Video Bug<br>2026-08-07<br>804 words<br>4 minutes<br>firefox windows arm64 debugging<br>For about two years, Firefox on my Windows on ARM machine kept telling me it needed to install video components on pages that had no video at all. Here&rsquo;s what was actually going on.

Hey everyone! Here is a story about something that has been nagging me for a couple of years until today, when I finally decided to solve it.<br>The Problem<br>As you may know if you have been reading this blog, I use Firefox.<br>A couple of years ago I picked up a Windows on ARM64 laptop, and while browsing the web I would sometimes get this banner:

The ridiculous thing is that the banner would appear exclusively on pages where there was no video or audio to play at all! Today I got it on the Tailscale Docs Homepage, which doesn&rsquo;t have any video or audio content.<br>For the past 2 years I&rsquo;ve been dismissing the issue as some kind of hyper-specific ARM64 problem, driven by the low adoption rate of Windows on ARM, and I figured it was just a quirk to live with. After all, it&rsquo;s not like I was missing out on any video content: YouTube, Netflix, Disney+ and other streaming services I use have always worked fine.<br>But, since today I had some time to kill, I decided to take a deeper look.<br>First red herring: codecs on ARM64<br>My first guess was some codec being only available on x64, but both gmpopenh264.dll and widevinecdm.dll (you can find them in your Firefox profile directory) are native ARM64 binaries, so that wasn&rsquo;t it.<br>Second red herring: broken installation<br>Then, I thought that maybe my installation was somehow broken, so I tried a clean installation of Firefox inside Windows Sandbox. After installing Firefox, I immediately got the same &ldquo;installing components&rdquo; banner on the Tailscale Docs homepage. So it wasn&rsquo;t a broken installation either.<br>Reproducing it with actual logs<br>Rather than keep guessing, I tried to reproduce the issue in a disposable Firefox profile with GMP (Gecko Media Plugin) and EME (Encrypted Media Extensions) logging turned on:<br>$env:MOZ_LOG = "timestamp,GMP:5,EME:5"<br>$env:MOZ_LOG_FILE = "C:\Users\andre\AppData\Local\Temp\firefox\firefox-gmp.log"<br>&"C:\Program Files\Mozilla Firefox\firefox.exe" -no-remote -new-instance -profile "C:\Users\andre\AppData\Local\Temp\firefox\temp_profile" https://tailscale.com/docs<br>The log showed tailscale.com/docs itself calling navigator.requestMediaKeySystemAccess() for a handful of DRM systems, despite the page having no video at all. I&rsquo;m not sure why, probably some kind of fingerprinting technique?<br>In any case, that&rsquo;s why the banner shows up on a page like this one. The actual bug was in what I saw next: the built-in Clearkey CDM (Content Decryption Module) was failing to load.<br>Right there in the log:<br>2026-08-07 14:08:15.807000 UTC - [Parent 23196: GMPThread]: D/GMP GMPServiceParent::mozilla::gmp::GeckoMediaPluginServiceParent::AddOnGMPThread(nsString)::(anonymous class)::operator(): C:\Program Files\Mozilla Firefox\i686\gmp-clearkey\0.1 Failed<br>Firefox was trying to load Clearkey from an i686 (x86) subfolder that doesn&rsquo;t even exist on my machine.<br>What&rsquo;s going on here? Why is it looking for an x86 plugin on an ARM64 machine?<br>Why an i686 folder at all?<br>In the olden days, Widevine had no native ARM64 CDM from Google at all, so Mozilla&rsquo;s only option was to run it as an x86 binary inside a separate, emulated plugin-container.exe child process (bug 1527811).<br>Clearkey — the W3C reference, unencrypted CDM used mostly for testing — was bundled the same way for consistency.<br>At some point Google started shipping a native ARM64 Widevine build too, and Mozilla shipped a native ARM64 Clearkey build alongside it (bug 1814703).<br>So the x86/emulation path isn&rsquo;t strictly needed for either anymore — it&rsquo;s just that Clearkey, being bundled directly by Mozilla rather than fetched from Google, still defaults to the old x86 route.<br>A follow-up bug, 1820669, was filed specifically to let the native ARM64 Clearkey plugin ship to Release and be preferred over the x86 one. It&rsquo;s RESOLVED FIXED, landed in Firefox 112 back in early 2023. But reading the actual bug comments:<br>we continue to ship with the x86 plugin at this time, so the users could switch back if necessary

So, the default was deliberately left pointing at the x86 path, as a safety net, even though the ARM64 plugin was available. The bug was closed, and the issue was never revisited.<br>The fix<br>Digging deeper, there&rsquo;s a preference for this, gating x86-vs-native selection independently for each GMP component (Widevine, OpenH264, Clearkey).<br>For Clearkey specifically, it&rsquo;s:<br>media.gmp-clearkey.allow-x64-plugin-on-arm64<br>It didn&rsquo;t exist in my about:config by default. After I created it and set it to false, Firefox started loading the native ARM64 Clearkey plugin directly, and the banner...