搜索 | 用户支持

防范以用户支持为名的诈骗。我们绝对不会要求您拨打电话或发送短信,及提供任何个人信息。请使用“举报滥用”选项报告涉及违规的行为。

详细了解

Can no longer play media with Firefox ESR 102.x

  • 53 个回答
  • 3 人有此问题
  • 304 次查看
  • 最后回复者为 OdeonFF

more options

Hello, ever since we moved endpoints from Firefox ESR 91.13 to 102.3, it has become impossible to play any media with Firefox.

No video will play in youtube, for instance (it just loads endlessly as if it would start, but it doesn't).

Can't use radio websites either. Anything with a "play" button (video or sound) does nothing.

This has been tested with a clean profile, a clean install, after allowing autoplay in the settings.

Is there any info on what exactly changed between ESR 91 and 102 that might explain this ? There has been no system change, If I reinstall 91 instead it works again as usual.

No issues anywhere else on the endpoints (Edge, Windows), this is on Windows 10 if it makes any difference.

Tanks for any help on this.

Hello, ever since we moved endpoints from Firefox ESR 91.13 to 102.3, it has become impossible to play any media with Firefox. No video will play in youtube, for instance (it just loads endlessly as if it would start, but it doesn't). Can't use radio websites either. Anything with a "play" button (video or sound) does nothing. This has been tested with a clean profile, a clean install, after allowing autoplay in the settings. Is there any info on what exactly changed between ESR 91 and 102 that might explain this ? There has been no system change, If I reinstall 91 instead it works again as usual. No issues anywhere else on the endpoints (Edge, Windows), this is on Windows 10 if it makes any difference. Tanks for any help on 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

定位到答案原位置 👍 1

所有回复 (13)

more options

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.

more options

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.

more options

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/

more options

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. =(

more options

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

more options

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.

由bruno.frisan于修改

more options

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

由OdeonFF于修改

more options

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.

more options

OdeonFF said

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.

more options

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.

more options

选择的解决方案

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

more options

OdeonFF said

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?

more options

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 !

  1. 1
  2. 2
  3. 3