I've since managed to duplicate this using both Firefox 0.8 and Mozilla 1.4 on a Mac running OS X 10.2.8 (not mine, hence not trying the latest Mozilla). It's not easy to do when things are running at normal speed, possibly a slow dial-up might make it easier to reproduce. Current method is to clear the cache, only one active window. Browse to an insecure page and type in the URL of the secure page but don't hit return. Position the mouse cursor over the padlock, hit return and click on the padlock the instant you see it lock. The media tab on the page info shows one image from the secure site, the title suggests it's the background graphic, and all other images are from the insecure site.
Based on the comments changing some fields and assigning to PSM.
This sounds like it could be part of the the same underlying flaw as bug 240053 which was fixed around 4/15. Does this still happen?
*** This bug has been marked as a duplicate of 258048 ***
I take that back, bug 258048 is sort of the opposite.
*** This bug has been marked as a duplicate of 257308 ***
Darin doesn't think this is a dupe, reopening
try for 1.8b and the point releases
I suspect that this may be a duplicate of bug 258048.
(In reply to comment #9) > I suspect that this may be a duplicate of bug 258048. Ok, I agree with dveditz. That bug seems like the opposite. It is likely that this is a duplicate of bug 240053 instead. I haven't been able to reproduce this bug yet using Firefox 1.0. I'm trying an older version to see if I can repro it there, just to verify my approach.
I'm unable to reproduce this. I'm not sure that it is a duplicate of either of those bugs, but I suspect that it may be a duplicate of one of the recently fixed lock icon bugs. The patch in bug 258048 gives me confidence that the URL bar will remain in sync with the lock icon state, and other patches give me confidence that we will not update the lock icon state until we are actually feeding data into the browser window, so I think we can mark this bug WORKSFORME. Please reopen this bug if you can reproduce the problem with a recent firefox 1.0.1 branch build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-aviary1.0.1/ or with a recent mozilla 1.7 branch build: http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-1.7/ Thanks!
I'm going to mark this as fixed1.7.6 and fixed-aviary1.0.1, even though it's really worksforme. Since we have fixed1.7.6 and verified1.7.6, it seems like we really should be calling the first keyword resolved1.7.6. In any case, that will make it show up on the appropriate lists. Darin, you were testing on the aviary 1.0 branch, right? And the relevant code is in sync for 1.7.6 (and for the suite), as well, right? If not, please remove these keywords...
dbaron: I tested this bug with Firefox 1.0 primarily. The other bugs I mentioned were tested across the board.
Verified WFM. Going from http to https we keep the secure url bar/lock icon synced with the secure page load.