User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.1) Gecko/20020826 Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.1) Gecko/20020826 I never saw this behaviour before this release (the last I used were 1.0, and 1.1b shortly) AFAIK, the HTTPS page is fully secure, and the HTTP is not at all (obviously). NB: I found bugs 83134 and 160195; I think they are related but different. Reproducible: Always Steps to Reproduce: 1. Start Mozilla, startup page is http://www.mozilla.org/ 2. Go to https://www.bourse2.caisse-epargne.fr/expl/Sicav/sicavfcp.html (from bookmark, or then with Forward button) 3. Clic Back button to come back My SSL preferences are: *loading SSL, leaving SSL, posting un2un: off *loading low, viewing mix: on Actual Results: I get the 'mix' warning, every time. Expected Results: Do not trigger the warning.

To PSM.

I cannot reproduce. I do not get the Mixed content warning when clicking on the back button.

See Additional Comment #3

(Obviously, the Attachment at Additional Comment #3 goes with this A.C. #4 :-<) Well, the case is strange enough that it does not surprise me if you can't reproduce it :-( On the other end, my installation is like this: *deleted previous instal., with manual additional cleanup of both disk and registry (AFAIK) *custom instal. *used a text editor to copy&paste my bookmarks to the "default" bookmark file in my new profile. Here are some more clues, for what they are worth: *Actually, it does happen (on my computer) when leaving <https://www.bourse2.caisse-epargne.fr/expl/Sicav/sicavfcp.html> to go to <http://www.mozilla.org/>, by either Back, Forward, Bookmark... *it does too when going to <http://www.firstinvest.com/> *(did not try with others: all I now is that it doesn't do it with <about:>) *If I rename my bookmark.html to something else, *bug still occurs with 'mozilla' URL *but not anymore with 'firstinvest' URL May be, try to reproduce with my user profile.!. May be it could be related with my cut&paste of bookmark lines ?? (anyway, it stands that I have done so for all the previous versions which I used: it would mean something changed in that area between v1.1beta and v1.1release !?)

Confirming. Reporter, can you set your disk cache to something higher than 0, and try again? That seems to be the problem. Edit>Prefs>Advanced>Cache.

I tried with Disk Cache set to 4096 Ko: this bug does not happen anymore ! (And it reappears when I set D.C. back to 0.) PS: I found bug reports about DC=0 and Flash, etc, but none about security ... here is one, then ;-<

Changing summary

With "Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2a) Gecko/20020910" Same bug: *happens with Disk Cache Disable, and DC Size=0. *does not happen with Disk Cache Enable, and DC Size=1024.

kai

Works for me with the 10/16 commercial Win2000 trunk build. The problem seems to have gone away.

"Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2b) Gecko/20021016" Opposite to AC#10: this bug is still there for me :-( Checked with DC disabled and set to 0.

"Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2) Gecko/20021126" *With DC=256, no bug. *With DC=0, bug still there.

[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3a) Gecko/20021212] Checked with DC disabled and DC size set to 0: bug still there. Could this bug be reassigned: it is there since v1.1 :-(

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212] As written in comment 13, and opposite to comment 10, this bug exists on current W2K build too.

I've also seen this bug on Linux.

This happens for me too despite the fact that I have 4096 kbytes of memory cache and 50000kbytes of disk cache. I have 'Compare the page when...' set to 'When the page is out of date'. It is important that the second (non-SSL) site is a bookmark. I don't see the problem if it is just an URL I type in. For example type in https://www.redhat.com/. Now go to bookmarked page, for example http://www.siliconinvestor.com/stocktalk/subject.gsp?subjectid=36138 I now get the mixed content error. Of course I have a tick in the "Viewing a page with an encrypted/unencrypted mix" box. I'm using 1.3A (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212). This bug has been here for quite a while.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212] Reply to comment 16: I confirm your test case: *(Same build and settings) Cache: Memory=4096, Disk=50000, Compare=OutOfDate. Only difference: *I got the bug at the first attempt, without a bookmark for the Http site. *(for a bit more about bookmarks, see comment 4 and description) Junruh: can you confirm that this bug is not limited to a "disabled / 0" disk cache ? Also, is there any timeframe defined for the current Target Milestone (PSM, Client Libray, v2.4) ?

Confirming comment #16. 1.) Set cache pref to When the page is out of date'. 2.) Visit http://www.siliconinvestor.com/stocktalk/subject.gsp?subjectid=36138 and bookmark it. 3.) Visit https://www.redhat.com/ 4.) Visit http://www.siliconinvestor.com/stocktalk/subject.gsp?subjectid=36138 using your bookmark, or any other insecure bookmarked site. You will get a warning about entering a site with a mix of encrypted/unencrypted info.

Thanks for your testcases. I now see the problem, too. Page 1: https://www.redhat.com Page 2: http://www.mozilla.org Test A: Open page 1 Open page 2 by clicking on the Browser icon in the upper right corner Test B: Open page 1 Open page 2 by entering the address into the URL field and pressing enter I confirm that test B behaves correctly, but test A behaves incorrectly as reported. I was able to find the cause of the problem. For some reason, the notification events sent to the security engine arrive in a different order in the tests. The bug is: Suppose page 2 consists of two parts: - the main html document - a style sheet, referenced from within the html document, not embedded, but loaded from a separate address In test A, loading of the stylesheet completes before loading of the main document!!! The current tracking code does not expected this scenario, actually, it surprises me things can happen in that order. The bug is: Once the style sheet finishes loading, the security state of the style sheet is checked. It is unsecure. The summarizing security state gets updated. However! The new security state of the toplevel document is not yet known, because it hasn't yet finished loading. (It is not known, because we track the security by extracing it from the SSL communcation channel - fixing 62178 would allow us to make a decision earlier by looking at the protocol that was involved.) Because the new state is not yet known, we are still using the previous security state for calculating the summarized state. Because the previous state was "secure", and we detect a insecure sub content, we bring up the mixed security warning. The fix is: After loading of a new top level document has started (we detect that), do not update the document's security state until the security state of the top level document gets known - only remember the security state of the sub contents. Once the new top level state is known, it will be set, and at that time, the collected information about already loaded sub content will get used. Once the new top level state is known, it is ok to update the security state based on sub document as it becomes known. Patch coming up.

Comment on attachment 112882 [details] [diff] [review] Patvh v1 r=javi

Comment on attachment 112882 [details] [diff] [review] Patvh v1 rs=darin

Comment on attachment 112882 [details] [diff] [review] Patvh v1 a=asa (on behalf of drivers) for checkin to 1.3beta.

Checked in, marking fixed.

Verified fixed.

*** Bug 187302 has been marked as a duplicate of this bug. ***

Unfortunately I have found additional problems. Please have a look at bug 191212.

[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3) Gecko/20030312] (Confirmed fixed for me.)