User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

0.1. Setup an OpenWRT router device with Luci. Make sure to not enable HTTPS. AFAIK it's HTTP-only by default. For more info, see https://openwrt.org/docs/techref/luci.
Basically, this is just a simple login frontend. Looking at the source it just uses a usual HTML form, as far as I see. HTML code: https://gist.github.com/rugk/4be17e1531ee3c443646907e959f58ac
0.2. Set dom.security.https_only_mode_https_first to true in about:config.

1. Go to your router login page at http://192.168.1.1/cgi-bin/luci
2. Enter any credentials.
3. Click "Login".

Actual results:

It basically just seems to reload the site. What it does under the hood from what I see, however, is that it tries to send an HTTPS POST request that never sucees with the credentials.
Meanwhile it reloads the page and gets a Forbidden error, because of a GET request.

Firefox sends the following response (executed using the different tools here):

As cURL (executed here):

$ curl 'https://192.168.1.1/cgi-bin/luci' -H 'User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Accept-Language: de,en-US;q=0.7,en;q=0.3' --compressed -H 'Content-Type: application/x-www-form-urlencoded' -H 'Referer: http://192.168.1.1/cgi-bin/luci' -H 'Origin: http://192.168.1.1' -H 'DNT: 1' -H 'Upgrade-Insecure-Requests: 1' -H 'Connection: keep-alive' -H 'Sec-GPC: 1' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' --data-raw ''
curl: (7) Failed to connect to 192.168.1.1 port 443: Connection refused

as fetch:

await fetch("https://192.168.1.1/cgi-bin/luci", {
    "credentials": "omit",
    "headers": {
        "User-Agent": "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0",
        "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8",
        "Accept-Language": "de,en-US;q=0.7,en;q=0.3",
        "Content-Type": "application/x-www-form-urlencoded",
        "Upgrade-Insecure-Requests": "1",
        "Sec-GPC": "1",
        "Pragma": "no-cache",
        "Cache-Control": "no-cache"
    },
    "referrer": "http://192.168.1.1/cgi-bin/luci",
    "method": "POST",
    "mode": "cors"
});

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://192.168.1.1/cgi-bin/luci. (Reason: CORS request did not succeed).
Uncaught (in promise) TypeError: NetworkError when attempting to fetch resource.

I also attached the full .har file. Note that I of course entered a wrong password, so nothing sensitive should be included in that file.

Expected results:

It should fallback to HTTP, should not it?

I.e. the login should succeed.

Note: I noticed it is also reproducible by simply doing the following:
0. (same steps as above, i.e. enable that option etc.)

1. Go to the HTTP login page of your OpenWRT router.
2. Right-click -> "View source"

What happens:
Again you get an error page:

Unable to connect

What should happen:
Again the view-source: should fallback to HTTP, should not it?

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Tomer, can you please take a look?

Are you successfully able to add an override for that domain, to tell it not to apply https-only to it? Option should show up in the site identity panel. not saying it's not a bug, just trying to give you a workaround.

Thanks for reporting it.
Since I don't have an OpenWRT router it will take me some time to reproduce it.

@Tomer Well, I guess you don’t strictly need to use an OpenWRT router. I’ve linked to the HTML page. If you host that on a HTTP site it may be reproducible.

Edit: Okay, just tried that on localhost with Python’s webserver and the network panel shows the HTTPS request, but also shows the HTTP fallback then, strange. So maybe indeed not so easy to reproduce.

@Daniel
No, in the stable FF I’m using I see no such option to exclude the site? (I’ll attach a screenshot.)

(The other shield pane also does not show me anything.)

I agree that we should try to fix that, though it's not a defect but rather an enhancement - updating...