From our dashboard, we've seen high volume of errors happened on the external state machine, I guess that there are something wrong for the mechanism of switching external state machine back to the normal state machine.

Set release status flags based on info from the regressing bug 1919627

It's possible that the initialization fail is caused by the users'
device don't support the media engine pipeline. In this case, we should
try to use the another state machine for playback, instead of just error
out.

Depends on D227772

Comment on attachment 9434975 [details]
Bug 1928798 - part1 : don't use ExternalEngineStateMachine if we already know the custom ident is used for non-supported CDM.

Revision D227772 was moved to bug 1928828. Setting attachment 9434975 [details] to obsolete.

Comment on attachment 9434976 [details]
Bug 1928798 - do not return fatal error if the initialization failed, try again with another state machine.

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Widevine L3 playback might be failed for some Windows users, due to their device capabilities
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): No any new feature added or big structure change, we just change the internal returned error code to prevent the playback failed.
• String changes made/needed:
• Is Android affected?: No

We will be able to monitor this dashboard to see if the issue is fixed or not.

https://hg.mozilla.org/mozilla-central/rev/733297b358c7

Comment on attachment 9434976 [details]
Bug 1928798 - do not return fatal error if the initialization failed, try again with another state machine.

Approved for 133.0b4

Comment on attachment 9434976 [details]
Bug 1928798 - do not return fatal error if the initialization failed, try again with another state machine.

Approved for 132.0.1.

Is manual testing needed for this bug? If yes, are there any specific steps we could use to manually verify this issue or would simply playing Netflix or other videos that use the Widevine plugin be sufficient?