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

Steps to reproduce:

install https://addons.mozilla.org/en-US/firefox/addon/violentmonkey/
install https://github.com/Purfview/IMDb-Scout-Mod userscript
go to a movie page on imdb like https://www.imdb.com/title/tt0102583/
enable a http search from userscirpt for http://kinozal.tv/ and save to refresh it
and http://kinozal.tv/ to https-only mode exceptions
use the script button to perform a search

Actual results:

the xhr request on page goes via https://kinozal.tv and fails

Expected results:

the xhr request on page should go via https://kinozal.tv

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

Shane, this sounds very similar to Bug 1714201. Is it a dupe or different because of background script and content script? Anyway, this has come up again - what's your take?

Yes, the background script problem is pretty different -- that's about not knowing the exception state of the open web page and whether to try to upgrade sub-requests or not. This is about exceptions for the sub-requests themselves.

Normally XHR to an insecure site like this would be blocked by the mixed-content blocker. Do we let extension content-scripts violate that? Possibly: moz-extension:// triggering principals get a pass on CSP so they might get a pass for the mixed-content blocker too.

I am clearing out super old ni?s, this is one of them.
Resetting flags so this bug shows up in dom:sec triage for re-evaluation.

I don't believe we could easily do this for just extension-run userscripts, but it's actually not an unreasonable desire to make https-only mode always respect exceptions—for sub-requests and not only the top level loads. This is a feature request, not a bug.

There could be unreasonable perf impacts.