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.

The Problem

As you may know if you have been reading this blog, I use Firefox.
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’t have any video or audio content.

For the past 2 years I’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’s not like I was missing out on any video content: YouTube, Netflix, Disney+ and other streaming services I use have always worked fine.

But, since today I had some time to kill, I decided to take a deeper look.

First red herring: codecs on ARM64

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’t it.

Second red herring: broken installation

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 “installing components” banner on the Tailscale Docs homepage. So it wasn’t a broken installation either.

Reproducing it with actual logs

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:

$env:MOZ_LOG = "timestamp,GMP:5,EME:5"
$env:MOZ_LOG_FILE = "C:\Users\andre\AppData\Local\Temp\firefox\firefox-gmp.log"
&"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

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’m not sure why, probably some kind of fingerprinting technique?
In any case, that’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.
Right there in the log:

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

Firefox was trying to load Clearkey from an i686 (x86) subfolder that doesn’t even exist on my machine.
What’s going on here? Why is it looking for an x86 plugin on an ARM64 machine?

Why an i686 folder at all?

In the olden days, Widevine had no native ARM64 CDM from Google at all, so Mozilla’s only option was to run it as an x86 binary inside a separate, emulated plugin-container.exe child process (bug 1527811).
Clearkey — the W3C reference, unencrypted CDM used mostly for testing — was bundled the same way for consistency.

At some point Google started shipping a native ARM64 Widevine build too, and Mozilla shipped a native ARM64 Clearkey build alongside it (bug 1814703).
So the x86/emulation path isn’t strictly needed for either anymore — it’s just that Clearkey, being bundled directly by Mozilla rather than fetched from Google, still defaults to the old x86 route.

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’s RESOLVED FIXED, landed in Firefox 112 back in early 2023. But reading the actual bug comments:

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.

The fix

Digging deeper, there’s a preference for this, gating x86-vs-native selection independently for each GMP component (Widevine, OpenH264, Clearkey).
For Clearkey specifically, it’s:

media.gmp-clearkey.allow-x64-plugin-on-arm64

It didn’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 disappeared.
BONUS: the pref lives in your profile, so it survives Firefox updates and reinstalls.

If you’re hitting this too

If you’re using Firefox on Windows on ARM64 and keep seeing that banner:

1. Open about:config.
2. Search for media.gmp-clearkey.allow-x64-plugin-on-arm64.
3. If it doesn’t exist, create it as a Boolean and set it to false. If it exists and is true, flip it to false.
4. Restart Firefox.

Till next time!