STR: 1. For extra fun, set security.warn_leaving_secure to true 2. Go to https://bugzilla.mozilla.org/buglist.cgi?bug_id=333751 3. Click the "RSS" link at the bottom of the list. 4. Get a warning that you are leaving a secure page for an insecure one, and when the feed at https://bugzilla.mozilla.org/buglist.cgi?bug_id=333751&ctype=rss loads note that the addressbar background is white, and that there's no lock icon.
The reason for this is: - the original content loads over https (secure) - the preview page is loaded from a jar channel (insecure) nsSecureBrowserUIImpl inspects the current channel for securityInfo and uses that to update the browser UI. In this "nested" channel situation we have no way of knowing what the securityInfo of the original channel is. This will potentially require significant API changes. Since this is lesser priority (worst case is user getting freaked out that content isn't secure when it actually is - anyway https: is still shown in location bar if coloration and lock icon isn't), I'm going to mark this not blocking.
related with bug 232944?
(In reply to comment #2) > related with bug 232944? I would more say no, but might be. At least, I don't believe fixing that bug will be sufficient to fix this one.
Seems more like fixing bug 482245 will help here because we change location of the page to file://.../subscribe.xhtml.
I promise I searched for this, but I used SSL and not HTTPS in my search. :(
The feed reader component has been mostly demoted in recent versions of Firefox, and we're unlikely to extend or expand on it. The bug mentioned here sounds relatively minor, and unique to the feed reader component, so I'm marking WONTFIX.
Appears to be fixed as of Firefox 47. I'm Running Firefox 47 on OpenBSD-current amd64, getting the correct padlock indicator when viewing RSS feeds over TLS.
FF49.0.2 Mac still shows this error. Have had to explain to customers that the issue is with Firefox, not services provided by my employ.