1333687 - Insecure-login-form UI appears incorrectly, in secure tab spawned from insecure page (at wedsure.com)

Status: VERIFIED DUPLICATE of bug 1329940

(Firefox :: Security, defect)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Visit http://www.wedsure.com/  (note: HTTP)
 2. Click "Sign in" at top right of page
  --> A new tab gets opened, at https://service.rvnuccio.com/admin/auth/login
     (note: this new tab is HTTPS)
 3. Click the username field, and see what happens.
    Click the site identity button (at left of URL bar), and see what happens.

 4. OPTIONAL: Manually open a new tab at the same URL, and repeat step 3 in that new tab for comparison.

ACTUAL RESULTS:
- In step 3 (in the auto-spawned tab), we show the insecure-form UI (with green external-validation UI alongside it). In step 4 (in the manually opened tab), we do not show any insecure form UI.

EXPECTED RESULTS:
Steps 3 and 4 should produce consistent results. They should both show no insecure form UI.

In particular, in step 3:
  * When I click the username field, I see the insecure-form warning dropdown ("This connection is not secure").  This is extremely confusing because we're showing the green external-validation UI in the URL bar.
 * When I click the site identity button, its dropdown has a lock with a slash through it, plus "Secure connection", plus "Logins entered on this page could be compromised".  (In other words, the UI is self-contradictory.)

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug (up through step 3, when the bug happens)

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screenshot of bug (at step 3, with insecure form UI & EV-site-identiy shown simultaneously)

Comment 3

[Daniel Holbert [:dholbert]]

BTW, the wrapping <form> element here is pointing at a secure URL, too, AFAICT -- it looks like this:
<form class="form-signin" method="post" action="/admin/auth/signIn" autocomplete="off" id="rvnaSigninForm" name="rvnaSigninForm" novalidate="novalidate">

Since this is an HTTPS (with EV) page, then relative URLs like "/admin/auth/signIn" can be assumed to also be secure.  So, AFAICT, there's no reason for the "Logins entered here could be compromised" UI.

Comment 4

[Johann Hofmann [:johannh]]

Thanks for including the precise STR. This is happening because window.opener points to an insecure page. See bug 1329940 for more info (we're working on it).

Comment 5

[Daniel Holbert [:dholbert]]

The form fields seem to be fixed now, via duplicate-target bug 1329940. Marking as VERIFIED dupe.

I spun off bug 1334201 for the Site Identity doorhanger issue here, which is not yet fixed.

I'm using latest Nightly 54.0a1 (2017-01-26) (64-bit)