Seen on Linux, but possibly a general behaviour - needs confirmation. Have a look at http://bugzilla.mozilla.org/show_bug.cgi?id=130949#c25 To summarize, doc loader seems to behave unexpected, when the user interrupts loading of pages, by clicking on links early (before loading has completed). When a user cancels loading of a page, the document loading of the new document also triggers some subdocuments from the previous document to be loaded. (again?) This wrong loading of unrelated subdocuments causes the security component to make wrong assumptions about the security state, and this causes wrong lock icon states shown to the user.

Actually, I think this is not a PSM bug. I would like to assign it to document loader or uri loader, but not finding a direct component match. People on #mozilla suggested to try embedding:docshell.

-> component owner

nominating nsbeta1/adt1.0.0. We've just done a lot of work on the lock icon, and the behavior depends on the doc loader to do the right thing.

Removing adt1.0.0 because there is no patch, nor reviews. Pls renominate for adt1.0.0 when the the patch is ready, and has review. This is a ADT1/nsbeta1+ because of security concern.

I'm not too familiar with how security information is passed around so I'm CC'ing a few people. I need pointers please.

Adam, I think the first thing to find out is: Why is doc loader loading those documents? Actually you should not be required to look at the security information at all. If the document loader behaved correctly, and would not trigger loading of some previous' document <iframe>s, everything would be fine. I'm updating the summary to state that more clearly. The doc loader's behaviour which I saw is explained in detail in comment 25 in bug 130949.

When a frameset document is canceled, it is possible that there are 'some' pending events for subdocuments that are pending in the current event queue... Could these events be showing up 'later' after the nsIRequest::Cancel() has occured? If this is the case, then calling nsIRequest::GetStatus(...) should return NS_BINDING_ABORTED for these requests... Perhaps the DocLoader should supress the START/STOP pair of notifications if both were pending when the request was canceled... Does this sound like what's happening? -- rick

when any document load is canceled, events will be posted to the main threads event queue. these can easily include OnStartRequest as well as OnStopRequest.

So, should the DocLoader simply 'supress' WebProgress notifications for ALL requests whose (GetStatus() == NS_BINDING_ABORTED) when OnStartRequest is 'processed'? This would prevent WebProgress notifications from being dispatch for requests that were 'completely' canceled. It is still important to send notifications for requests that are only 'partially' canceled (ie. STATE_START has fired). will this solve the problem? It should be fairly simple to implement... -- rick

hmm.. instead of checking if the request has a failure code of NS_BINDING_ABORTED, we should probably check the loadgroup for a status of NS_BINDING_ABORTED. if the loadgroup has been canceled, then it makes sense to suppress notifications for requests in that loadgroup that have not even fired OnStartRequest yet. however, if we just trigger off of the request's status, then we may hit some problems with usages of NS_BINDING_ABORTED that don't correspond to the user clicking a link or otherwise stopping a page load. (e.g., meta-charset reload calls Cancel(NS_BINDING_ABORTED) iirc.)

This probelem occur only on Linux, or on all platforms?

Rick, Darin, thanks for your suggestions. Right now I wanted to test whether I can confirm the presence of the NS_BINDING_ABORTED flag. But I can no longer reproduce the problem. The page now loads correctly. From my perspective, we can set this to worksforme. But I'm curious, did you change something that could have fixed this problem? Jamie, at the time I saw this behaviour, I only tried Linux. If you want to see whether it is fixed for you, too, please try: - go to http://www.bouldernews.com/ - before loading completes, click on the "subscribe" link in the upper right corner Expected behaviour: closed lock icon, "secure page" warning. Former wrong behaviour: mixed lock icon, "mixed content" warning.

yup, WORKSFORME 2002040808 linux.

I'll mark this WORKSFORME but Rick please take it or raise a new bug if you want to implement some failsafes in the docloader.