Lock icon broken on displayed even if pageloading was secure. Major regression.

I'm not sure if this should be a smoketest blocker since it didn't come up in this morning's smoketests so I've asked the smoketesters about it.

On |OnEndDocumentLoad| of the windows content we are getting the security information of the channel that loaded us by calling |nsHTTPChannel::GetSecurityInfo|. This calls |nsHTTPRequest::GetTransport|, and by this time the mPipelinedRequest request is null, and we return null as the security information of the page load.

i thought pipelining is turned off by default....it seems strange that we would be accessing a pipelining variable. is this okay?

I thought it was off as well, but I clearly hit code like this: if (mPipelinedRequest) return mPipelinedRequest -> GetTransport (aTransport); else *aTransport = nsnull;

Piplined request is the same structure as nsHTTPRequest used to be. When pipelining is turned off - it behaves just like the old httprequest. Every request holds a reference to it's parent pipelined request. So I don't see how this could cause a regression.

Oops. You're right. For some reason the backpointer to the the original request wasn't set. I'll fix it in a sec.

Fixed now.

I assume the fix isn't in 2000041008, as clicking the lock icon causes hang/freeze (?)

No. It's just merely to display it.

Reopening. The fix made it into the Linux build, but the 2000041109 build for Windows is still busted.

The fix was cross-platform? What's the reason for Windows bustage? Is it just because of the wrong build?

Marking fixed. I had "Enable Mem Cache" turned off in windows.

Verified.