This was found in the context of bug 165301. While that one could be fixed by a change to PSM, other pages have been found that still do not work correctly. This bug is also causing the lock icon on slow modem connections to temporarily go to a wrong state. See bug 187302. Problem description: When navigating from https to http on certain web pages, where all content on the https page comes from https, and where all content on the http page comes from http, the browser does incorrectly report a page with mixed security. How to reproduce: I see this problem on Windows only. The only *reliable* test case I've found so far requires a paid mail account at https://www.gmx.net 1.) go to https://www.gmx.net, confirm the "enter secure page" message 2.) enter username and password, login 3.) as soon as the content from the next page is displayed, while the rest of the page is still loading, click logout in the upper left corner 4.) you'll see a warning message about mixed security 5.) you'll see message about leaving a secure site The bug is step 4. This message is incorrect and should not be shown. I've played around, and sometimes I've been able to reproduce it without having to use a paid account. Alternative, less reliable test case: 10.) Prepare the locations in the dropdown URL bar by going to https://www.gmx.net/de/cgi/nph-logout 11.) Go to https://www.gmx.net, confirm the "entering secure" message 12.) Click into the user name field in the upper left and hit enter 13.) While the next page is loading, quickly reselect the https://www.gmx.net/de/cgi/nph-logout URL from the dropdown list and hit enter. 14.) If you're lucky, you'll see the bug, showing the "mixed content" message 15.) The "leaving secure" message is shown. Again, bug is step 14. Cause of the bug: The implementation of security state tracking uses web progress notifications sent out from the document loading process. The implementation assumes that there is no overlapping between the notifications for loading different toplevel document. It assumes it is not necessary to track events from multiple document loads at the same time, because notifications will be sent as part of separate isolated notification transactions. In other words, the implementation assumes: - while document A is loaded, only notifications for document A, or for any URL that is part of its content, will be sent - if the user decides to go to document B, there will not be any notification sent out for document B, unless all notifications related to document A have arrived at the STOP level. When debugging the above test case, I saw the above assumption is not assured. I saw that two START notifications for LOAD_DOCUMENT_URI are received, without receiving a STOP LOAD_DOCUMENT_URI notification in between. (However, I discovered, in the above case, the second request has the LOAD_REPLACE flag set in addition.) This completely confuses the current tracking logic. Question: Is it a bug that the progress notifications are sent out that way? If it is not a bug, the tracking logic in PSM needs improvement. It must find a way to assign notifications to the separate document loading transactions. I recently learned about "load groups". Maybe PSM must be extended to check the load group of any notified request. However, I wonder whether this bug is another argument to rather work on bug 62178. If the security transition warnings were not dependent on an outside notification process, but rather would be integrated directly into the document loading process, PSM could make a much easier decision whether a transition between an unsecure protocol and a secure protocol is happening.

> Question: Is it a bug that the progress notifications are sent out that way? Where's rick when you need him? ;) I suspect that this is incorrect, yes. Any idea what's triggering the LOAD_REPLACE? My first guess would be some sort of JS, but....

I am able to reproduce the bug even with JS disabled. I suspect the LOAD_REPLACE is caused by the redirection that is triggered on the logout page. When you click logout, you are first sent to a https page, but it immediately redirects to a http page.

The https logout page sends a 302 code, setting the location to http.

Oh. Yeah, that would case a LOAD_REPLACED. We should be notifying LOAD_STOP on that first one, I would think.... Any idea who's actually sending you the notifications? Doesn't look like it's the docloader...

adt: nsbeta1-

reassign bug owner. mass-update-kaie-20120918

The implementation of the mixed content detection has changed significantly since this bug was filed, and I can't reproduce the issue, so I think this has been fixed (if not, please reopen with STR).