User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 If you go to an https mixed content page - you get a broken lock. If you go to another page and then back to the previous page - Mozilla thinks the mixed page is now secure (yellow bar and good lock). If you now reload the page - the broken lock now re-appears. To fix this - you may have to add the security status of a page to the cached copy (and/or show a broken lock when there are cached inclusions in a secure page page). As a sidenote - may I suggest you flag broken lock pages with a RED bar color. Reproducible: Always Steps to Reproduce: 1. go to an https:// page that is mixed content (like no-https style sheet) 2. go to another page 3. go BACK (to the page in step one) 4. Reload (the page in step one) Actual Results: 1. broken lock 2. open lock 3. good lock (this is the problem) 4. broken lock Expected Results: 1. broken lock 2. open lock 3. broken lock 4. broken lock This may be related to these bugs: Bug 140837 Bug 191212 Bug 255242

WFM in Firefox 2.0.0.2pre which should have the same behavior, and this sounds like a "bfcache" problem we fixed quite a while ago. Maybe someone using SeaMonkey can repro...

I can't reproduce this in SM1.1 on XP.

I installed the Windows version with the seamonkey-1_1_en-US_win32.zip file I will do some more tests (to check if it affects more than one or two machines/users and to check if it shows up on more than one platform as well). I will see if I can't put together a PUBLICLY accessible test page for you.

Sounds like a duplicate of bug 358438.