Chrome and Safari both support
upgrade-insecure-requests but don't have this problem.
If you open a new window and attempt to load https://www.smartbus.org/Schedules/Trip-Planner (note: secure) you get the same redirect as in comment 0 but we do follow the redirect in that case. We appear to be ignoring the
upgrade-insecure-request in the redirect itself.
In the steps given in comment 0, however, the main smartbus page does have
content-security-policy: upgrade-insecure-requests; -- Firefox is applying it to navigations and Chrome+Safari are not. Or rather, Firefox is applying it deeply to navigations, and maybe Chrome+Safari are only rewriting the original URL. According to the spec, same-site navigation links should get upgraded, but it's not clear about after that. A lot of the spec is written in terms of "rewriting links" which would seem to skip redirects. But other parts of CSP are pretty clear about redirects being included, and §4.1 includes the note
Note: Due to [FETCH]'s recursive nature, this algorithm will upgrade insecurely-redirected requests as well as insecure initial requests.
This is curious.
Karl: Firefox appears to be following the spec here. Although we're in the minority and it results in this site being broken, this is a true webcompat problem that needs to be resolved before just accepting it as a Firefox bug. We can try to guess what Chrome and Safari are doing, but then we could end up broken differently elsewhere if we guess wrong. Although the site is broken, we have broken it in the secure direction. If we try to match Chrome and don't get it right we could end up broken in the insecure direction on some other site. Should https://webcompat.com/issues/81130 be re-opened?