User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 Steps to reproduce: Server returns content-security-policy: upgrade-insecure-requests; header along with content which mostly has http only URL references in it. Actual results: Browser correctly upgrades all resource loads and link clicks to https - confirmed with web developer tools, only https requests are being made. However, a password input field on a login form gives the Insecure password warning when entering data into it. Expected results: Since page was loaded over https and form will be submitted via https the warning should not display. On the surface it appears as though the Insecure password warning is not taking the impending upgrade to https into account when deciding if its appropriate or not.

This looks nearly as the same as bug 1334760. The password is requested from a http content. That it gets submitted via https doesn't mean that the http content can access the password.

My apologies, i have left something out. In my case, the login form or any other actual content from this host can not be loaded via http - all requests to http are redirected via a 301 Moved Permanently response header to the same url over https. Its looks like this request http://blah.blah -> receive 301, location is https://blah.blah request https://blah.blah -> receive 302 Found, location is http://blah.blah/login, csp upgrade-insecure-requests is set request http://blah.blah/login -> receive 301, location is https://blah.blah/login request https://blah.blah/login -> load content, csp upgrade-insecure-requests is set So the page with the password input box is indeed loaded over https. It may be worth noting explicitly that the plain http requests do NOT have CSP upgrade-insecure-requests set (aws load balancer is doing the 301 to https) but the actual content is still loaded over https.