Yes, it's a HKCU value so I'm not sure it's really important. I deleted it several time and it recreates it with a value where it just won't work afterwards, unless I fix it to 0.

It's possible that the problem stems from our install then, since for a long time it wasn't auto-update, and it only started to be auto-update when we made the switch from 91.13 to 102.3.

I'm still anoyed that recreating the value to its "default" (letting Firefox recreate it) breaks media playback...From your link though, I understand that these two keys (Browser and Launcher) are leftovers and should be reset by Firefox during install anyway. Why the new value blocks media is weird.

Another location contacted us today saying they were now affected after switching to ESR 102.4.

We have moved to 102.5 today and the problem remains.

It's now clear that the issue stems from the launcher process. Breaking the registry key has the effect of disabling the launcher process, Firefox recreates it as 0 if it's the only one deleted, and will recreate it with a random value if I delete the whole HKEY_CURRENT_USER\SOFTWARE\Mozilla\Firefox\ folder.

I'm still unable to find how to fix the launcher process so that it stays enabled, and doesn't cause this unintended behavior.

Now that the problem is clearer, I searched for any open bugs and didn't find one. Can you file on Bugzilla here:

https://bugzilla.mozilla.org/

Submitted Bug 1800869, let's hope for the best.

Hopefully someone has an inkling as to why the launcher process is doing this. If it's because of some side-effects from another GPO or our endpoints configuration, I can deal with it, but I don't know what has changed with the launcher process between ESR 91 and 102 that might do this. =(

Glad to know we are not the only ones having this issue! What a pain!

About:config - "browser.launcherProcess.enabled" By default it is set to "true". Changed that to "false" and restart Firefox. It got our youtube working again. With this setting set to "true" Firefox blocks DLL injections by third party applications. This apparently was done for stability. Setting it to "false" with get you working again but will be subject to third party DLL/plugin injections.

Hello Bruno, yep, that "fixes" it, sadly this isn't the expected behavior, I've opened a bug report to try and find out why the launcher process acts like this, as it's not perfect to have to disable, and more importantly, it's not designed for industrialization (the setting can't be made default)...Can't remember the bug report for that but apparently, it was never intended to be a user setting.

I wish I knew why this happened. I need to try mozregression to find out when the issue happened between 91.13 ESR and 102.3 ESR

Alright, so in case anyone is still encountering this problem, it appears (for us) that the problem is a process mitigation setting that we push during the master of our endpoint.

Starting from Firefox 102.0, having the following values set to true means, unless the launcher process is deactivated, that we can't read media.

• EnableExportAddressFilter="true"
• EnableExportAddressFilterPlus="true"
• EnableImportAddressFilter="true"
• EnableRopStackPivot="true"
• EnableRopCallerCheck="true"
• EnableRopSimExec="true"

You can check what settings are enabled/disabled with Powershell, running "Get-ProcessMitigation -name firefox.exe"

I still don't know why it is so with 102.0 and up only.

Alright, so in case anyone is still encountering this problem, it appears (for us) that the problem is a process mitigation setting that we push during the master of our endpoint.

Thank you for reporting back. Whatever change this was probably was introduced in a regular release between the ESR releases of Firefox 91 and Firefox 102.

I wonder whether any of the changes associated with "fission" (site isolation) could be relevant (https://hacks.mozilla.org/2021/05/introducing-firefox-new-site-isolation-security-architecture/). Perhaps you could test with the launcher process still enabled but with fission.autostart set to false to see whether that makes any difference. In case no one has tried that already.

Hello, sadly, it didn't solve the issue.

But I think we're getting close now. On the bug report, it was suggested that our exploit protection settings might be obsolete, I'm looking into this.

Ok, so this is -as far as I can tell- resolved.

Our Windows 10 21H2 was still using the baseline Microsoft exploit protection for Windows 10 1803, and there was a conflict with Firefox.

Removing those obsolete settings and instead using the proper 21H2 baseline file fixed the issue.

Relevant data: Fixing current exploit protection mitigation settings Reference including the current baseline

Ok, so this is -as far as I can tell- resolved. Our Windows 10 21H2 was still using the baseline Microsoft exploit protection for Windows 10 1803, and there was a conflict with Firefox. Removing those obsolete settings and instead using the proper 21H2 baseline file fixed the issue. Relevant data: Fixing current exploit protection mitigation settings Reference including the current baseline

That is great news. I wonder whether we should create a help article here?

It might be worth doing though I'm sure the issue is relatively uncommon, it would only affect organizations applying an out of date baseline xml for process mitigation during deployment of Windows 10.

Whatever helps people find the solution more easily =) !

Anyway, thanks for all the help !