1558924 - [10.15] Widevine crashes on macOS Catalina Beta

Status: VERIFIED FIXED

(Core :: Audio/Video: GMP, defect, P1)

Description

[Sören Hentzschel]

Attachment: screenshot (de)

STR:

Start a DRM protected video on macOS 10.15 Beta 1.

Expected:

Video plays.

Actual:

First a dialog appears saying that libwidevinecdm.dylib can't be opened because it's from an unverified developer. Then Widevine crashes.

Crash report:
https://crash-stats.mozilla.org/report/index/e1c4a5b5-84a0-4840-a85f-9c42c0190612

Comment 1

[Nils Ohlmeier [:drno]]

Attachment: Netflix error

Screen shot of the Netflix error, which is probably just a generic widevine crash error.

Comment 2

[Nils Ohlmeier [:drno]]

Attachment: App security settings

This happens even when set to the more relaxed "App store and identified developers". The "open anyway" button only attempts to launch the widevine plugin from command line (which is obviously useless).
I have not been able to find something where I can choose to trust the plugin going forward to avoid all the problems.

Comment 3

[stddef]

Hey Guys, I found a solution for you that might be helpful, as it was for me. I'm currently running build 19A487I which is 10.15 Beta 2, and I followed the instructions put out by techjunkie when MacOS Sierra was launched, which had a similar issue with the feature behind this error with side-load launching apps outside of the Apple Developer platform.

Basically you are looking to get the gatekeeper service, to bring back the master setting for "Anywhere" as the setting called: "App Store and identified developers" simply means the developer app still has to have an official Apple signature.

Assuming you already have SIP disabled, which you can check the status of by running csrutil status in your terminal;
Go ahead and run sudo spctl --master-disable in your terminal, and then quit & reload the system preferences application with the Security & Privacy tab option open.

You should see the "Anywhere" selection option open again, and for good measure, to make sure it's really being followed, select one of the other options, navigate out of that pane, restart system preferences, and navigate back to it again and re-select the "Anywhere" option.

When I restarted my computer I was able to get Chromium, Firefox Nightly, and Firefox Developer to load the module.

Hope this helps!

Comment 4

[stddef]

Sorry I forgot to add:
If you want to prevent the gatekeeper from coming back automatically, run:
sudo defaults write /Library/Preferences/com.apple.security GKAutoRearm -bool NO

(In reply to stddef from comment #3)

Hey Guys, I found a solution for you that might be helpful, as it was for me. I'm currently running build 19A487I which is 10.15 Beta 2, and I followed the instructions put out by techjunkie when MacOS Sierra was launched, which had a similar issue with the feature behind this error with side-load launching apps outside of the Apple Developer platform.

Basically you are looking to get the gatekeeper service, to bring back the master setting for "Anywhere" as the setting called: "App Store and identified developers" simply means the developer app still has to have an official Apple signature.

Assuming you already have SIP disabled, which you can check the status of by running csrutil status in your terminal;
Go ahead and run sudo spctl --master-disable in your terminal, and then quit & reload the system preferences application with the Security & Privacy tab option open.

You should see the "Anywhere" selection option open again, and for good measure, to make sure it's really being followed, select one of the other options, navigate out of that pane, restart system preferences, and navigate back to it again and re-select the "Anywhere" option.

When I restarted my computer I was able to get Chromium, Firefox Nightly, and Firefox Developer to load the module.

Hope this helps!

Comment 5

[cihadturhan]

@stddef I'm sure your method works but it seems like a security flaw. I'm okay with SIP enabled but I wonder if there is a way without disabling anything such as adding exception to this specific "unidentified developer"

Comment 6

[stddef]

You’re absolutely correct @cihadturhan, it’s just meant to be a bandaid, until there’s a real fix. The problem is that I don’t know if Apple will ever fix gatekeeper, as it poses an issue for many other areas as well, like signature settings on node based PWAs, individually authored kernel extensions, any third party C compilers, Apple may not know of, etc. Gatekeeper disabled, is what is required to side-load apps from unidentified developers, and SIP controls enabled mean you cannot disable gatekeeper. Once Apple de-couples these two, maybe we will have a better solution?

(In reply to cihadturhan from comment #5)

@stddef I'm sure your method works but it seems like a security flaw. I'm okay with SIP enabled but I wonder if there is a way without disabling anything such as adding exception to this specific "unidentified developer"

Comment 7

[Nick Thomas [:nthomas] (UTC+12)]

I don't think the Widevine binary is signed by Google:

$ codesign -vvv ~/Library/Application Support/Firefox/Profiles/<profile>/gmp-widevinecdm/4.10.1196.0/libwidevinecdm.dylib
libwidevinecdm.dylib: code object is not signed at all
In architecture: x86_64

We have the same problem with openh264, which is only gpg signed on mac.

Comment 8

[richardf9661]

I just wanted to point out that this issue is only affecting Firefox Quantum/Nightly, and Safari, not Chrome.

The error code for Safari is the following: https://imgur.com/a/wYgxmTR
The error code for both Mozilla Quantum/Nightly is the following: https://imgur.com/a/FenOQyE

Note that I'm still getting the WidevineCdm crash even though Gatekeeper has been disabled. Disabling Gatekeeper is what actually allowed me to use Firefox Nightly again...

This appears to be an issue with macOS as a whole and I have submitted a report using the "Feedback Assistant".

Comment 9

[Haik Aftandilian [:haik]]

I forgot that we already had a bug on file for this issue and filed 1561731. I'll dupe 1561731 to this bug.

We may have two issues here. In 10.15, there are new rules about executing quarantined applications and this might apply to loading of the CDM dylib by the GMP process. The GateKeeper dialog implies it is.

With quarantining disabled, we have a crash in Apple library code called by the CDM. See crash stack below. Do we have a Widevine contact we can reach out to about this?

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
    frame #0: 0x00007fff6982c752 libdispatch.dylib`_firehose_task_buffer_init + 266
libdispatch.dylib`_firehose_task_buffer_init:
->  0x7fff6982c752 <+266>: ud2    
    0x7fff6982c754 <+268>: cltq   
    0x7fff6982c756 <+270>: leaq   0x15020(%rip), %rcx       ; "BUG IN LIBDISPATCH: Unable to get the unique pid (size)"
    0x7fff6982c75d <+277>: movq   %rcx, 0x2d9929ac(%rip)    ; gCRAnnotations + 8
Target 0: (plugin-container) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
  * frame #0: 0x00007fff6982c752 libdispatch.dylib`_firehose_task_buffer_init + 266
    frame #1: 0x00007fff6980c5fe libdispatch.dylib`_dispatch_client_callout + 8
    frame #2: 0x00007fff6980d776 libdispatch.dylib`_dispatch_once_callout + 20
    frame #3: 0x00007fff6982b415 libdispatch.dylib`voucher_activity_get_metadata_buffer + 100
    frame #4: 0x00007fff69a7fca5 libsystem_trace.dylib`_os_trace_init_slow + 94
    frame #5: 0x00007fff6980c5fe libdispatch.dylib`_dispatch_client_callout + 8
    frame #6: 0x00007fff6980d776 libdispatch.dylib`_dispatch_once_callout + 20
    frame #7: 0x00007fff69a7fbfb libsystem_trace.dylib`os_log_create + 784
    frame #8: 0x00007fff5fd322cd SkyLight`__SLSLogInit_block_invoke + 28
    frame #9: 0x00007fff6980c5fe libdispatch.dylib`_dispatch_client_callout + 8
    frame #10: 0x00007fff6980d776 libdispatch.dylib`_dispatch_once_callout + 20
    frame #11: 0x00007fff5fe0c606 SkyLight`__SLSInitialize_block_invoke + 375
    frame #12: 0x00007fff6980c5fe libdispatch.dylib`_dispatch_client_callout + 8
    frame #13: 0x00007fff6980d776 libdispatch.dylib`_dispatch_once_callout + 20
    frame #14: 0x00007fff5fcfc18d SkyLight`CGS_CHECK_INIT + 80
    frame #15: 0x00007fff5fe88b82 SkyLight`SLSGetOnlineDisplayList + 45
    frame #16: 0x00007fff5fec9111 SkyLight`SLGetOnlineDisplayList + 41
    frame #17: 0x0000000112d042d0 libwidevinecdm.dylib`___lldb_unnamed_symbol2520$$libwidevinecdm.dylib + 128
    frame #18: 0x0000000112d0414a libwidevinecdm.dylib`___lldb_unnamed_symbol2515$$libwidevinecdm.dylib + 26
    frame #19: 0x0000000112c84828 libwidevinecdm.dylib`___lldb_unnamed_symbol1099$$libwidevinecdm.dylib + 168
    frame #20: 0x0000000112cd1597 libwidevinecdm.dylib`___lldb_unnamed_symbol2156$$libwidevinecdm.dylib + 199
    frame #21: 0x000000010db6f70a XUL`___lldb_unnamed_symbol105639$$XUL + 554
    frame #22: 0x000000010bdfba76 XUL`___lldb_unnamed_symbol42938$$XUL + 5958
    frame #23: 0x000000010ba4f60f XUL`___lldb_unnamed_symbol32233$$XUL + 431
    frame #24: 0x000000010ba504c6 XUL`___lldb_unnamed_symbol32244$$XUL + 422
    frame #25: 0x000000010ba10e93 XUL`___lldb_unnamed_symbol31350$$XUL + 1971
    frame #26: 0x000000010ba11aba XUL`___lldb_unnamed_symbol31356$$XUL + 730
    frame #27: 0x000000010f902480 XUL`___lldb_unnamed_symbol171207$$XUL + 4128
    frame #28: 0x000000010a7c7f13 plugin-container`___lldb_unnamed_symbol1$$plugin-container + 99
    frame #29: 0x00007fff6985d3f9 libdyld.dylib`start + 1

Comment 11

[Haik Aftandilian [:haik]]

I'm still hitting the crash with the new Widevine version 4.10.1440.18.

Comment 12

[Haik Aftandilian [:haik]]

More clear stack trace:

(lldb) bt
* thread #1, name = 'MainThread', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x538acec6)
  * frame #0: 0x00007fff71700995 libsystem_platform.dylib`_platform_bzero$VARIANT$Haswell + 53
    frame #1: 0x00000001116705d6 libwidevinecdm.dylib`VerifyCdmHost_0 + 1918326
    frame #2: 0x0000000111645fd7 libwidevinecdm.dylib`VerifyCdmHost_0 + 1744759
    frame #3: 0x000000011149a599 libwidevinecdm.dylib
    frame #4: 0x0000000111497bdd libwidevinecdm.dylib
    frame #5: 0x000000011149c1b7 libwidevinecdm.dylib`VerifyCdmHost_0 + 343
    frame #6: 0x000000011149c026 libwidevinecdm.dylib`CreateCdmInstance + 54
    frame #7: 0x0000000108b9a551 XUL`mozilla::ChromiumCDMAdapter::GMPGetAPI(char const*, void*, void**, unsigned int) + 193
    frame #8: 0x0000000108bb0036 XUL`mozilla::gmp::GMPContentChild::RecvPChromiumCDMConstructor(mozilla::gmp::PChromiumCDMChild*) + 102
    frame #9: 0x00000001069f82b8 XUL`mozilla::gmp::PGMPContentChild::OnMessageReceived(IPC::Message const&) + 1352
    frame #10: 0x0000000106838853 XUL`mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) + 467
    frame #11: 0x0000000106839c08 XUL`mozilla::ipc::MessageChannel::MessageTask::Run() + 440
    frame #12: 0x00000001067f4a84 XUL`MessageLoop::DoWork() + 1940
    frame #13: 0x00000001067f5882 XUL`base::MessagePumpDefault::Run(base::MessagePump::Delegate*) + 1218
    frame #14: 0x000000010ab10de2 XUL`XRE_InitChildProcess(int, char**, XREChildData const*) + 4626
    frame #15: 0x00000001052e3f07 plugin-container`main + 103
    frame #16: 0x00007fff715033f9 libdyld.dylib`start + 1

Comment 13

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Thanks for the further information. Thanks for checking the signing in comment 7, Nick.

Looking at the libwidevinecdm.dylib in Chrome (lives somewhere like /Applications/Google Chrome.app/Contents/Versions/74.0.3729.169/Google Chrome Framework.framework/Versions/A/Libraries/WidevineCdm/_platform_specific/mac_x64/libwidevinecdm.dylib) compared to ours, Google appear to have signed the Chrome version but not the one we're given. I'm following up with Widevine regarding this.

Edit: it's not clear to me this is the root cause of the issue, but seems like something worth following up on given the difference.

Comment 14

[Haik Aftandilian [:haik]]

These crashes appear to be caused by sandboxing restrictions not allowing proc_pidinfo syscalls.

I found that the crash in libdispatch.dylib`_firehose_task_buffer_init with message "BUG IN LIBDISPATCH: Unable to get the unique pid (size)" was due to a call to proc_pidinfo failing which was due to our CDM sandbox not permitting that. Our CDM sandbox rules include "(deny process-info*)" and with an addition of "(allow process-info* (target self))" Widevine playback with Netflix is crash-free.

I don't know why this wasn't a problem in earlier macOS verisons. libdispatch.dylib`_firehose_task_buffer_init does exist in macOS 10.14 and does call proc_pidinfo and then crashes on error. It could be that the CDM doesn't execute the same code paths on 10.14 and earlier due to some other changes in 10.5.

I'll test the fix more and then post for review.

Comment 15

[Haik Aftandilian [:haik]]

Attachment: Bug 1558924 - [10.15] Widevine crashes on macOS Catalina Beta r?handyman

Allow limited access to the proc_pidinfo() syscall from the GMP sandbox.

Comment 16

[Haik Aftandilian [:haik]]

The posted fix uses (allow process-info-pidinfo (target self)) instead of the more board (allow process-info* (target self)) for backwards compatibility with older macOS releases which don't support the wildcard process-info* in allow rules. And testing shows only the process-info-pidinfo variant is needed to avoid these CDM crashes. Tested on 10.9, 10.14, and 10.15 Beta 2.

Comment 17

[Haik Aftandilian [:haik]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=4a2687ad11e74e7d8dc10d6f907ecc70ffa3abee

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/83204e889b72
[10.15] Widevine crashes on macOS Catalina Beta r=handyman

Comment 19

[richardf9661]

I've just updated to the Public Beta 2 (19A501i) and while using Firefox Quantum v.67.0.4 (20190619235627) and Firefox Nightly v.69.0a1 (2019-07-03) (64-bit), the same issue as in the Public Beta 1 persists.

Comment 20

[Haik Aftandilian [:haik]]

(In reply to richardf9661 from comment #19)

I've just updated to the Public Beta 2 (19A501i) and while using Firefox Quantum v.67.0.4 (20190619235627) and Firefox Nightly v.69.0a1 (2019-07-03) (64-bit), the same issue as in the Public Beta 1 persists.

Thanks for the report. We've got a fix for the CDM crashes expected to be in Firefox Nightly later tomorrow. If that is successful, we might be able to get the fix into Firefox 68 to be released on the 7th.

To clarify, 19A501i is considered 10.15 Public Beta 3 per https://developer.apple.com/news/releases/?id=07022019e

Comment 21

[richardf9661]

(In reply to Haik Aftandilian [:haik] from comment #20)

(In reply to richardf9661 from comment #19)

I've just updated to the Public Beta 2 (19A501i) and while using Firefox Quantum v.67.0.4 (20190619235627) and Firefox Nightly v.69.0a1 (2019-07-03) (64-bit), the same issue as in the Public Beta 1 persists.

Thanks for the report. We've got a fix for the CDM crashes expected to be in Firefox Nightly later tomorrow. If that is successful, we might be able to get the fix into Firefox 68 to be released on the 7th.

To clarify, 19A501i is considered 10.15 Public Beta 3 per https://developer.apple.com/news/releases/?id=07022019e

Perfect! I'm glad to read a solution was found. Sorry about that mistake regarding the Publica Beta 2 vs 3. I would edit my post to correct it if possible.

Comment 22

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/83204e889b72

Comment 23

[Haik Aftandilian [:haik]]

I've just tested today's Nightly with the fix and am still running into crashes. I'm working on debugging this.

Comment 24

[Haik Aftandilian [:haik]]

(In reply to Haik Aftandilian [:haik] from comment #23)

I've just tested today's Nightly with the fix and am still running into crashes. I'm working on debugging this.

I didn't realize that the sandboxing fix was insufficient because my testing was done on a machine with System Integrity Protection (SIP) disabled. I had disabled SIP on the machine while debugging and failed to retest again with SIP enabled. What that means is that after fixing the sandbox issue described in comment 14, we are still running into crashes loading the Widevine dylib from our CDM process. (Now I'm testing with a Hardened Runtime build that includes the debugging entitlement, but is not Notarized.)

Our Hardened Runtime / Notarized builds use the com.apple.security.cs.disable-library-validation entitlement to allow loading of signed third party dylibs (i.e. signed, but not with the same identity as the loading process). But our Widevine dylib is not signed. We are working with the Widevine team to debug this further.

I have not had the fix backed out and will check with Releng on the best way to handle this.

Comment 25

[Haik Aftandilian [:haik]]

Current status of this bug: the fix that landed was incomplete (see explanation in comment 24). It fixed one crash with Widevine on the Catalina Beta, but the full fix is dependent on bug 1566127 and bug 1566523.

With bug 1566523 now on Nightly, Widevine playback on Nightly on Catalina works for new profiles.

Once bug 1566127 lands, the problem should be resolved for existing profiles once they update to the Widevine CDM version 4.10.1440.19.

Comment 27

[Bogdan Maris, Desktop QA]

ESR versions are also affected by this (both 60.8esr and 68.0.2esr) when using new profiles, and that's because of bug 1566127. Waiting for 4.10.1440.19 to be served on esr builds as well. After that I can verify this bug on the remaining branches. Haik, is 4.10.1440.19 scheduled soon for esr?

Comment 28

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

(In reply to Bogdan Maris [:bogdan_maris], Release Desktop QA from comment #27)

ESR versions are also affected by this (both 60.8esr and 68.0.2esr) when using new profiles, and that's because of bug 1566127. Waiting for 4.10.1440.19 to be served on esr builds as well. After that I can verify this bug on the remaining branches. Haik, is 4.10.1440.19 scheduled soon for esr?

We're planning on rolling out .19 to ESRs this week. It's been baking in beta without issue, and I'll request required rule changes and uplifts in the next couple of days unless blockers arise.

Comment 29

[Haik Aftandilian [:haik]]

(In reply to Bogdan Maris [:bogdan_maris], Release Desktop QA from comment #27)

ESR versions are also affected by this (both 60.8esr and 68.0.2esr) when using new profiles, and that's because of bug 1566127. Waiting for 4.10.1440.19 to be served on esr builds as well. After that I can verify this bug on the remaining branches. Haik, is 4.10.1440.19 scheduled soon for esr?

Bogdan, this is not critically important, but could you confirm which version of Catalina Beta and which ESR you are testing?

Although bugs 1566127, 1566523 are both dependencies, due to a change in Catalina Betas (described on 1570840), I think the crash will not be reproducible with the fix for this bug and just bug 1566523 on Catalina Beta 6. I believe that in Beta 4, Apple made bug 1566127 not be required to fix this, but we still want to roll out the signed CDM versions.

Comment 30

[Bogdan Maris, Desktop QA]

(In reply to Haik Aftandilian [:haik] from comment #29)

(In reply to Bogdan Maris [:bogdan_maris], Release Desktop QA from comment #27)

ESR versions are also affected by this (both 60.8esr and 68.0.2esr) when using new profiles, and that's because of bug 1566127. Waiting for 4.10.1440.19 to be served on esr builds as well. After that I can verify this bug on the remaining branches. Haik, is 4.10.1440.19 scheduled soon for esr?

Bogdan, this is not critically important, but could you confirm which version of Catalina Beta and which ESR you are testing?

Although bugs 1566127, 1566523 are both dependencies, due to a change in Catalina Betas (described on 1570840), I think the crash will not be reproducible with the fix for this bug and just bug 1566523 on Catalina Beta 6. I believe that in Beta 4, Apple made bug 1566127 not be required to fix this, but we still want to roll out the signed CDM versions.

I tested using Catalina beta 6 (19A536g) and with both 60.8.0esr (buildID: 20190702220624) and 68.0.2esr (buildID: 20190813155538) and got crashes in Netflix and Amazon Prime.

Comment 31

[Haik Aftandilian [:haik]]

(In reply to Bogdan Maris [:bogdan_maris], Release Desktop QA from comment #30)

I tested using Catalina beta 6 (19A536g) and with both 60.8.0esr (buildID: 20190702220624) and 68.0.2esr (buildID: 20190813155538) and got crashes in Netflix and Amazon Prime.

Thanks. I realize now we need the patch for this bug uplifted to 68, 68esr, and 60esr [Edit, not needed in 60esr, only needed in 68 if Catalina ships before Firefox69]. I'll file the uplift request. The ESR builds will have to be new enough to include this bug fix and bug 1566523. I'll get the uplift request filed.

Comment 32

[Haik Aftandilian [:haik]]

Comment on attachment 9075748 [details]
Bug 1558924 - [10.15] Widevine crashes on macOS Catalina Beta r?handyman

Beta/Release Uplift Approval Request

• User impact if declined: On macOS Catalina (and the Catalina Beta builds), Widevine playback (used for Netflix and Amazon Prime streaming) will cause plugin process crashes and will not be functional.
  macOS Catalina will probably not release before build 69 ships, so this may not be worth uplifting to the 68 release.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Verify Widevine playback works as expected on the latest Catalina Beta release.
• List of other uplifts needed: Bug 1566523, Bug 1566127
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The change is a low risk Mac sandboxing change to make the gecko media plugin (GMP) sandbox slightly more permissive to allow an additional system call.
• String changes made/needed:

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Widevine playback is a very important feature and it will not be functional on macOS Catalina with 68esr without this fix.
• User impact if declined: On macOS Catalina (and the Catalina Beta builds), Widevine playback (used for Netflix and Amazon Prime streaming) will cause plugin process crashes and will not be functional. This fix is also dependent on bugs 1566523 and 1566127.
• Fix Landed on Version: 69
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The change is a low risk Mac sandboxing change to make the gecko media plugin (GMP) sandbox slightly more permissive to allow an additional system call.
• String or UUID changes made by this patch:

Comment 33

[Haik Aftandilian [:haik]]

I'm marking this bug as fixed in 69 and 70 because the fix landed for this bug in 69, but Widevine playback continued to crash due to additional bugs. See comment 24 and comment 25. The dependencies are fixed with uplifts in progress.

Comment 34

[Haik Aftandilian [:haik]]

This fix is not needed in ESR60 because its version of the GMP sandbox rule set did not block the process info system call.

Comment 35

[Camelia Badau [:cbadau], Desktop QA]

We tested on macOS 10.15 Catalina beta 6 (19A536g) using Firefox 69 Beta 15 and Netflix and Amazon Prime correctly work; no crashes occur.

Comment 36

[Anca Soncutean, Desktop QA]

Netflix and Amazon Prime are also working properly on macOS 10.15 Catalina beta 6 (19A536g) with Firefox 70.0a1 (2019-08-21).

Comment 37

[Julien Cristau [:jcristau]]

Comment on attachment 9075748 [details]
Bug 1558924 - [10.15] Widevine crashes on macOS Catalina Beta r?handyman

gmp sandbox fix for macos 10.15, approved for 68.1esr.

Not planning another 68 dot release as 69 is going to be out soon, so a- for mozilla-release.

Comment 38

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/releases/mozilla-esr68/rev/4f6134ab70f2

Comment 39

[Anca Soncutean, Desktop QA]

I’ve retested this issue on macOS 10.15 Catalina beta 6 (19A536g) with the official 68.1.0esr and Netflix/Amazon Prime are working without any problems. I will not change the ESR status to verified or remove the qe+ flag, until Widevine version 4.10.1440.19 will be going live and I recheck this bug.

Comment 40

[Anca Soncutean, Desktop QA]

I’ve retested this issue on macOS 10.15 Catalina beta 6 (19A536g) with the official 68.1.0esr and Netflix/Amazon Prime are working without any problems. I will not change the ESR status to verified or remove the qe+ flag, until Widevine version 4.10.1440.19 will be going live and I recheck this bug.

This issue is verified fixed with Widevine version 4.10.1440.19.