Firefox 132.0 Breaks Netflix, 132.0.1 Still Broken?

Firefox 132.0 breaks Netflix at the point content should start streaming, with Netflix error code F7361-1253-806E0005, as tested on Windows 10 22H2, Firefox 32-bit on 64-bit Windows.  

This is positioned as a DRM issue (no surprise, as DRM is code designed to break playback), said to be fixed in Firefox 132.0.1, but I'm still seeing the same failure pattern.

Well, bugs like this can happen; that's Strike One - but wait, this reveals two deeper issues...

1: No way to undo a toxic update

If your code needs to be "updated" (i.e. fixed) so often that automatic updates are preferred (at least by the vendor), then you need to be humble about such updates, in case they create new problems.  That means the ability to undo an update that may be messing things up - but I can't find that facility in Firefox; Strike Two. 

2: Update breaks data?

Fortunately, I kept a full offline installer for the previous version of Firefox, to undo whatever the latest update may have broken.  I could install that over the newer code base as an "upgrade"; no warnings about version revision or side effects.  But when Firefox started after this version fall-back, it warned: "Using an older version of Firefox can corrupt ... an existing Firefox profile.  To protect your information, create a new profile for this version of Firefox".  

Only choices from that modal dialog box were Exit or Create New Profile.  I certainly did not want to botch my profile by starting a new one that might lose all "my stuff", so chose to Exit. Strike Three.

Now, this worrying if this is not specific to 132.0, i.e. if Mozilla thinks it's OK to routinely botch user profiles and "just" spawn new ones, whenever one tries to undo a toxic update.  Changing data compatibility is non-trivial, should seldom happen, and be well-tested and documented if it does.  

A bland "well, we may botch your data, so let us 'protect' you as the only way to run the program, or go away" doesn't cut it, especially with no further details on what would happen if one "just" starts a new profile.  That approach amounts to "Trsut us, we're a software vendor" when the competence layer of the trust stack is already broken by the toxic update.

I re-installed broken 132.0, used Edge instead, watched for a bug-fix version, saw 132.0.1, downloaded and installed that, and lo!  Netflix still broken.  I presume the Netflix issue will eventually be fixed, or maybe it's something specific to my setup, making "Strike One" a "No Ball".  But now we've caught the "man behind the curtain" on Strikes Two and Three, not sure if I'll go back for more of the same.

Black but Working BCD Boot Menu; A Fix

In the age of UEFI PCs running Windows 10 and later, you may find a situation where the BCD Boot Menu is invisible as a black screen, but still works if navigated from the keyboard.  Enter will end the timeout, arrow keys will change the selection, etc.

This problem pattern is not the same as others that are more commonly described online; the menu that does not appear because it is bypassed (Fast Start, Timeout = 0, etc.) or other boot issues that may use a different BCD, bypass the BCD altogether, boot the wrong storage device, hang or crash before reaching UEFI boot due to hardware issues, etc.  

Recently I saw my 3rd case of this problem pattern, having described the first and second cases previously.  In all three cases, the boot menu works just fine, but can't be seen because the screen (or all screens, if multiple connected) stay black.  There's signal to the screen that the monitor accepts, rather than suspending due to incompatibility, but everything is black, with no visible mouse pointer or text-mode blinking cursor.

One fix is to disable the graphics adapter in Windows Device Manager, forcing Windows to use the Microsoft Basic Adapter driver instead of the driver specific to the system's GPU (as detected by Windows).  This proves this to be a "kick away the ladder" metabug, where something that should affect only Windows (the choice of graphics driver) affects the underlying UEFI system level beneath, with the potential to make it impossible to boot Windows to undo the damage.

Another fix for older systems, is to avoid UEFI in favor of CSM "BIOS", but this option is no longer available with Class 3 UEFI, and is increasingly untenable as Windows and hardware evolves.

Today's fix is to force the "legacy" type of BCD Boot Menu via a BCDEdit setting, specifically...

bcdedit /set "{current}" bootmenupolicy legacy

 ...where "{Current}" can be replaced with "{Default}" or more specific OSLoader GUIDs, as displayed explicitly via the /V option in BCDEdit. The visible impact is a text-mode white on black boot menu instead of the blue graphic boot menu; also, the menu text for OSLoaders that use RAMDisk will be taken from the RAMDisk defining GUID in BCD, rather than the OSLoader's GUID.

The implications of all this are twofold. 

First, the pre-Windows UEFI boot process is affected by choice of drivers in Windows, extending to how the BCD registry hive is interpreted by {bootmgr} (as seen from BCDEdit).

Second, the code that processes the BCD to display the Boot Menu has two pathways; that of the Windows 7 era Boot Menu that still works when forced via "bootmenupolicy legacy", and the newer Windows 10 era code that screws up the display when problematic drivers are in effect.

The safety implications go deeper; that an attack can be made through Windows to "brick" the system at the pre-Windows UEFI system level, such that no storage device can boot.  "Windows" device drivers should not integrate into the system as firmware "Extensions"!