Order of web progress notifications cause false mixed secure content warnings



Core Graveyard
Security: UI
16 years ago
2 years ago


(Reporter: kaie, Unassigned)


(Blocks: 1 bug)

Other Branch
Windows 2000

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [kerh-coz])



16 years ago
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

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
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
     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
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....

Comment 2

16 years ago
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.

Comment 3

16 years ago
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...


15 years ago
Keywords: nsbeta1

Comment 5

15 years ago
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-


13 years ago
Component: Security: UI → Security: UI
Product: PSM → Core


13 years ago
Whiteboard: [kerh-coz]
QA Contact: junruh → ui

Comment 6

6 years ago
reassign bug owner.
Assignee: kaie → nobody
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).
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME


2 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.