Reported by Matthew Kogan from bug 1339059 comment #3 User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0 Build ID: 20170125094131 Steps to reproduce: Open http://www.huffingtonpost.co.uk/ Actual results: No console warning about insecure logins but the address bar shows a lock with a strike-through. Expected results: No lock with a strike-through since there isn't a *login* form on the page.

The problem is that the ad network is auto-submitting a hidden form (that doesn't have login fields) but bug 1166947 introduced a regression that caused form submissions to cause a form to be added to `loginFormRootElements` for the document state from `earlyformsubmit` even if they don't contain login fields. `_detectInsecureFormLikes` uses `loginFormRootElements` to know if there are login forms present.

I see twitter is doing this on the page along with huffingtonpost itself along with another ad network I saw do this earlier on the page so I've seen three hidden form submissions on this URL alone. <form style="display:none;" class="_hp_xd_elements" id="_xd_form_id_1487381850950" name="_xd_form_1487381850950" action="http://www.huffingtonpost.com/users/provider/xd_handler.php" target="_xd_frame_1487381850950" method="POST"><input name="site" value="uk" type="hidden"><input name="sync" value="local" type="hidden"></form>

This situation underlines a deeper issue; that HTTPS pages can contain data from multiple sources, yet the 'padlock' info lists only the primary source. Surprisingly, provided that the third-party data is covered by *ANY* SSL certificate, not necessarily the declared one, then no warning will be shown. Yet, third party data is far more likely to be a source of security issues such as Trojans or MITM attacks. Seems to me that if the padlock states: Data is secured by Verisign Content is provided by [whatever.trustedsite.com] Then that must be true all of the time. -Possibly a separate issue but thought it was relevant here.

We don't have then plan for 51 dot release. Mark 51 won't fix.

Mass wontfix for bugs affecting firefox 52.

This was marked as a P1 bug back in early March but hasn't seen any activity since. Is this something we should continue tracking or should we drop the priority?

Too late for 54, let's see if we can fix it in 55.

(In reply to Ryan VanderMeulen [:RyanVM] from comment #6) > This was marked as a P1 bug back in early March but hasn't seen any activity > since. Is this something we should continue tracking or should we drop the > priority? It should stay P1 for when Password Manager actually gets resourced.

This is a P1 bug without an assignee. P1 are bugs which are being worked on for the current release cycle/iteration/sprint. If the bug is not assigned by Monday, 28 August, the bug's priority will be reset to '--'.

Lower priority as http: is going away over time.