I always thought that "mixed content" was defined as mixing "secure" and "insecure" origins (where a "secure origin" could be either https://something or http://localhost) and not literally mixing http and https urls. But this would explain the problem.

To my knowledge, https on loopback doesn't give you any kind of added security: Everything with enough privileges to capture the encrypted packets on loopback also has enough privileges to just capture the unencrypted memory directly. And "localhost" is also a single "domain", so a cert wouldn't even give you the ability to distinguish between different origins (as other ports or hostnames that resolve to 127.0.0.1 would do)

So it's just some buerocratic hoops to jump through to satisfy browsers.

Edit: I remember reading about some objection that the "localhost" domain could be resolved to something other than 127.0.0.1, either through the hosts file or through a faulty DNS resolver.

I think those objections were addressed in the "let localhost be localhost" proposal which mandated that the hostname "localhost" must be hardwired to 127.0.0.1 in the OS/browsers/resolvers etc and must never be permitted to point to anything else.

But maybe this proposal didn't gain traction and so browsers are defending against such rebound localhost domains.

In that case, I'd try and check if "http://127.0.0.1" works, as the IP address can't be rebound in the same way as the hostname.

Edit2: And of course there is the issue with everything that is defined on top of TLS itself, e.g. ALPN and HTTP2. If you want to test anything involving that, you'll of course need to run TLS on localhost and are gonna need a cert too.