139730 - https page containing <iframe> incorrectly shows mixed security warning

Status: VERIFIED WORKSFORME

(Core Graveyard :: Security: UI, defect, P1)

Description

[Steffen Motzer]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+)
Gecko/20020423
BuildID:    20020423

When I go to the URL https://webmail.t-online.de/ Mozilla warns me that I am
viewing a page with encrypted and unencrypted content and the lock symbol is red.

After copying the URL

https://bannerssl.t-online.de/werbung/service/webmaillogin200-300.html

into the navigation toolbar, Mozilla loads the page and the yellow lock symbol
indicates that no unencrypted content was loaded.

When I click the back-button to return to https://webmail.t-online.de/ the lock
symbol stays yellow! Even if I reload the page (in a new Mozilla window) the
lock symbol is yellow.

Reproducible: Always
Steps to Reproduce:
1. Go to https://webmail.t-online.de/
2. Paste this URL into the navigation toolbar:
https://bannerssl.t-online.de/werbung/service/webmaillogin200-300.html
3. Use the back button to go back to the previous page.

Actual Results:  Mozilla no longer warns me that parts of the page at
https://webmail.t-online.de/ (maybe the file favicon.ico ?) were not transmitted
securely.

Expected Results:  The lock symbol should be red.

Comment 1

[Boris Zbarsky [:bzbarsky]]

to PSM

Comment 2

[Stephane Saux]

John, this should probably be duped. Kai's work on the lock icon fixed that.
build 2002041711 works on win2k.

Comment 3

[Kai Engert [:KaiE:]]

> John, this should probably be duped. Kai's work on the lock icon fixed that.
> build 2002041711 works on win2k.

Well, Steffen says, he is seeing the problem with build 20020423.

Comment 4

[Kai Engert [:KaiE:]]

I can reproduce this bug with a trunk based build on Linux.

I can not reproduce this bug on a 1.0.0 branch based build.

Therefore this bugs looks like a new regression on the trunk.

Comment 5

[Kai Engert [:KaiE:]]

Some first trace results:

On our initial attempt to extract the security state, by obtaining security info
from the channel and QIing it to nsITransportSecurityInfo, we fail.

The current implementation assumes, if we are using security, this will succeed,
and will not try again later - causing the insecure lock icon to appear.

Comment 6

[Kai Engert [:KaiE:]]

This bug seems to only occur with pages having an <iframe>.
I uploaded a simpler test case showing the problem at
https://www.kuix.de/misc/test14/

But note, I do not agree with the initially changed expected behaviour.

It is a bug that the red icon is shown, because all content gets transfered securly.

Actual behaviour: Mixed security icon is shown and mixed security warning is shown.

Expected behaviour: The "good" lock icon should be shown all the time.

Comment 7

[Stephane Saux]

regression.

Comment 8

[Jaime Rodriguez, Jr.]

Removing nsbeta1+/adt2, as this is not seen on the branch.

Comment 9

[John Unruh]

This appears to be working now with this build: Mozilla/5.0 (Windows; U; Windows 
NT 5.0; en-US; rv:1.0rc2) Gecko/20020510

Comment 10

[Kai Engert [:KaiE:]]

John, I believe what you tested is a branch build (1.0.0 rc2). The problem is
seen on the trunk only, I still see it.

Comment 11

[Kai Engert [:KaiE:]]

I can no longer reproduce using a current trunk build.

Comment 12

[John Unruh]

Verified works for me with the 7/17 Win32 trunk.