lock icon and certificates spoofable with any insecure protocol this report is an extension of bug 277564. the problem reported there can be reproduced using "window.opener.location=" and any URL type that results in a document that never finishes loading. the real bug is that we don't update the lock icon until we get OnStateChange(STATE_STOP) for the toplevel document. I will post a testcase, derived from the one in bug 277564, shortly.

OK, here's my testcase: http://friedfish.homeip.net/test/bugs/278003/test.html It is derived from this one: http://beta51.minutedesign.com/test2-3.html

bz's comment in bug 277564 comment 19 makes sense to me. But what we should do IMHO is to show an unsecure lock as soon as we start getting data, and on STATE_STOP 'upgrade' it to a secure or whatever lock.

(In reply to comment #2) > But what we should do IMHO is to show an unsecure lock as soon as we start > getting data, and on STATE_STOP 'upgrade' it to a secure or whatever lock. I thought of that at first, but won't we then end up triggering the entering/leaving SSL dialogs all over the place? I know most people turn them off anyway, but we' need to be careful not to make it totally useless.

yeah, i agree... we should not show the secure lock icon until we know that everything is secure. perhaps we could show the mixed icon while the page is loading.

maybe we need another lock state... a lock with a question mark on it or something :-)

yeah, rather a questionmark (or no icon at all?) then the mixed one since the mixed looks more secure then the page might actually be.

hm... what is the problem with showing the secure icon in the first STATE_TRANSFERRING? that icon will show the right state for the currently displayed content - everything secure. as soon as something insecure arrives, the icon will be updated accordingly. why's this a problem?

biesi: yeah, that may be fine provided we display the security state change dialogs at the right time :-/

We have had several similar timing bugs with the lock icon. We need to attack them as a group and then regression test against all the dependencies of bug 130949 (alias: lockicon).

try for 1.8b and tbe point releases

Marking this bug as a duplicate of the earlier report. They are essentially the same thing. *** This bug has been marked as a duplicate of 258048 ***