Very related to https://bugzilla.mozilla.org/show_bug.cgi?id=512188, checkIfURIisSecure[1] uses documentURI to decide if a page is secure, when it should be using the uri associated with the principal of the top level page. Up until now, this method was just used for webconsole messages. But now (or very soon) it is used to determine the security UI of the page in bug https://bugzilla.mozilla.org/show_bug.cgi?id=1179961 If http://example.com does a window.open(about:blank) and puts a password field in the new page, checkIfURIisSecure will return true instead of false when using documentURI. If we instead use the principal of the page (which would have inherited from example.com) we would see that it is http://example.com and correctly return false. We should keep this bug hidden as long as 512188 is hidden, since they are essentially about the same issue. In 512188 we talk about potential attacks where one website can steal the password of another; I have not been able to come up with any live examples. In this bug the threat model is different - it is about websites applying tricks to evade the downgraded security UI. On the other hand, the website could also evade the UI by obfuscating the password field. But that would mean that the password manager would not work with the site. This may or may not be acceptable to them. Marking this as blocks https://bugzilla.mozilla.org/show_bug.cgi?id=1179961 because technically it does block getting that right, but we should go ahead and land 1179961 when it is ready and look at this bug as a followup. [1] method is currently here but will soon be moving locations with https://bugzilla.mozilla.org/show_bug.cgi?id=1193341 https://mxr.mozilla.org/mozilla-central/source/toolkit/components/passwordmgr/InsecurePasswordUtils.jsm#50

I think this got addressed in bug 1217766. Tanvi/Matt, can you doublecheck?

(and in fact, based on that, maybe we should close bug 512188 as wfm?)