472986 - (Also in Linux) FF3.1B2 - "broken lock" appears after logging into online banking site - OK with FF3.0

Status: RESOLVED DUPLICATE of bug 455367

(Core Graveyard :: Security: UI, defect)

Description

[Michael K]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2

After logging into online banking site, when actually selecting the "Pay my bills" option, the page displays properly, but the green security lock icon becomes red, and the part of this page contains insecure content..." dialog appears. Link to post at Mozillazine above. <br>
This does not happen in FF3.0, (I have both available) and this happens in both Ubuntu (GNU/Linux) and the Windows XPSP3 versions.  Others on that thread have seen similar instances, but not an exact reproduction and I can not find a "public" site in which to test to reproduce specific procedure.

Reproducible: Always

Steps to Reproduce:
1. Log in to online banking site and then select "pay my bills"-Sorry I can not provide URLs and passwords... :)
2. Upon loading, once secure site now becomes insecure.
 
Actual Results:  
Unable to proceed due to possible security issue of online banking details being unencrypted.

Expected Results:  
As happens in Firefox 3.0 - entire session stays secure.

OEM can only report that they do not support users beta testing browsers.  I have investigated this with them, and posted all data at the URL indicated above.
This could impact other areas where secure connections are required, but I do not have the resources to investigate further.

Comment 1

[Matthias Versen [:Matti]]

Which security information does Firefox show if you doubleclick the lock icon ?

Comment 2

[Daniel Veditz [:dveditz]]

From mozillazine it appears the online bank is "Digital Insight" and they use "Checkfree" for their online bill paying. Maybe we can find a developer which an account using one of those two who can investigate further.

Firefox 3.0 has several bugs in detecting "mixed content", in particular insecure images and CSS are allowed through. It's possible the site has this configuration and it simply wasn't noticed before. Some other browsers instead silently drop insecure content, or prompt the user whether to show it or not.

The default "Media" tab in page info only seems to show images and plugin content, but several addons will show the full included content on the page. One I use is called "View Dependencies" which adds a tab to the Page Info dialog, and you can inspect this information with Web Developer Toolbar. If you have it AdBlock Plus can also show a list of loaded ("blockable") elements in a page, but if you don't I recommend the others instead as AdBlock is pretty heavyweight for this purpose.

Comment 3

[Michael K]

I have "No Script" but had it disabled.  I will try using the safe mode today and see if that makes a difference.  

Is there a way to save the output of the "Error Console" or other output data pages (other than multiple screen captures?)

Is there a "Developer mode/Debug mode" I can enter to get further info? 

I <really> want to address this for the community for this could be an issue - and , of course, for myself. ;)

MRK

Comment 4

[Michael K]

Attachment: Attachment1

Comment 5

[Michael K]

Attachment: Attachment 2

Comment 6

[Michael K]

Attachment: Attachment 3 - with note.

I pointed this bad URL to them and they made no comment - I presume their "404" site is also HTTPS?

Comment 7

[Michael K]

(In reply to comment #1)
> Which security information does Firefox show if you doubleclick the lock icon ?

See the above 3 attachments - also note on #3: "I pointed this bad URL to them and they made no comment - I presume their "404" site is also HTTPS?"

Comment 8

[Michael K]

(In reply to comment #3)
>  I will try using the safe mode today> 

This still happens in "Safe Mode".

MRK

Comment 9

[Matthias Versen [:Matti]]

>I presume their "404" site is also HTTPS?"
Easy to test yourself if you open the "invalid" link in a browser window/tab alone but as far as i can tell they don't do a redirect to http:// 

Is everything under the media tab with http:// instead of https:// ?

The error with the site is a mixed content warning.

Comment 10

[Michael K]

(In reply to comment #9)
> Is everything under the media tab with http:// instead of https:// ?>

Yes, everything is https.  The URL I arrowed in the illustration is apparently the text to the page, so it's "OK".

This only switches to the Insecure mode in the last instant before the page loads.  Isn't there ANY way to "Debug" this?

MRK

Comment 11

[Jesse Ruderman]

Nelson / Honza, do you know how Michael can debug this?

Comment 12

[Honza Bambas (:mayhemer)]

Here http://hg.mozilla.org/mozilla-central/annotate/8c4f6932ab41/security/manager/boot/src/nsSecureBrowserUIImpl.cpp#l575 is code that tracks the number of subdocument loads. If one of low, broken or no security counters is raised, then icon turns to broken (red).

Hope it's what you need. Feel free to ask here for help.

Comment 13

[Michael K]

Cool.  Never saw the sourcecode-and that's just a "smidgen" of the whole thing for sure...  Of course it's all just C++ to me (may as well be Greek!)

Aha, but the question is:

What here is different than what was in Firefox 3.0???  That's the key!

MRK

Comment 14

[Michael K]

Cool.  Never saw the sourcecode-and that's just a "smidgen" of the whole thing for sure...  Of course it's all just C++ to me (may as well be Greek!)

Aha, but the question is:

What here is different than what was in Firefox 3.0???  That's the key!

MRK

Comment 15

[Johnathan Nightingale [:johnath]]

Hey Michael - thanks for your help trying to debug this.  Let's give something a try, if you're game.

Below I'm going to put a javascript: URL.  If you haven't used one before, the deal is this:

1) you open a tab to your bank, login, and get to the page with the broken padlock.
2) You paste one of the javascript URLs below into your address bar while on the bank's page and hit enter.
3) That code will scan for a particular type of content that may be misbehaving.

**In general, you shouldn't paste javascript URLs into places with confidential information because the code could try to steal it.  **

But in this case, if you trust me or inspect it yourself, all it's doing is walking a bunch of elements from the page to see if they contain http references and then popping up annoying dialog boxes.

Does that make sense?

Here are some to try.  Paste everything including the "javascript:" right up to the end of that block of code, into your address bar and hit enter.

This one looks for iframe tags:

javascript:count=0;tags = document.getElementsByTagName("iframe"); for(i = 0; i < tags.length; i++) { if(/^http:/.test(tags[i].src)) { alert("iframe with http url: " + tags[i].src); count++}} alert("Total http refs found: " + count);

This one looks for script tags:

javascript:count=0;tags = document.getElementsByTagName("script"); for(i = 0; i < tags.length; i++) { if(/^http:/.test(tags[i].src)) { alert("Script from http url: " + tags[i].src); count++}} alert("Total http refs found: " + count);

This one looks for link tags:

javascript:count=0;tags = document.getElementsByTagName("link"); for(i = 0; i < tags.length; i++) { if(/^http:/.test(tags[i].href)) { alert("Document links to http url: " + tags[i].href); count++}} alert("Total http refs found: " + count);

Your checking in Page Info has already confirmed no images are to blame.  If neither of these turn up results, we can try other tags, but I would guess it was one of these as a first pass, and I don't want to make you try 50 things at a time.

Comment 16

[Michael K]

1. This one looks for iframe tags:

javascript:count=0;tags = document.getElementsByTagName("iframe"); for(i = 0; i
< tags.length; i++) { if(/^http:/.test(tags[i].src)) { alert("iframe with http
url: " + tags[i].src); count++}} alert("Total http refs found: " + count);

Response in dialog box: Total http refs found: 0
*****
I reloaded page to confirm still insecure and to clear Address bar, then paste and enter next one:
2. This one looks for script tags:

javascript:count=0;tags = document.getElementsByTagName("script"); for(i = 0; i
< tags.length; i++) { if(/^http:/.test(tags[i].src)) { alert("Script from http
url: " + tags[i].src); count++}} alert("Total http refs found: " + count);

Total http refs found: 0
****
I reloaded page to confirm still insecure and to clear Address bar, then paste and enter next one:
3. This one looks for link tags:

javascript:count=0;tags = document.getElementsByTagName("link"); for(i = 0; i <
tags.length; i++) { if(/^http:/.test(tags[i].href)) { alert("Document links to
http url: " + tags[i].href); count++}} alert("Total http refs found: " +
count);

Total http refs found: 0
***
Well Is "none" a good thing or a bad thing:  :)

MRK

Comment 17

[Nelson Bolyard (seldom reads bugmail)]

I have this same frustration.  When I do my online banking, every page shows
the mixed content icon (and if I enable it, the mixed content warning dialog).
I see this every time I visit 
  https://sitekey.bankofamerica.com/sas/signonScreen.do?state=CA
(This is the login page, you don't need an account to see that page)

Like Michael K, I have examined the pages, and find no http:// references 
in them.  I also ran Johnathan's 3 javascripts and saw three alerts reporting
zero found.

I think there is another bug for this problem, and that this like likely a 
duplicate of that one.  I'll try to find it again.

Comment 18

[Eddy Nigg (StartCom)]

Nelson, using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090106 Shiretoko/3.1b3pre shows the page correctly (and accompanying Larry icon).

Comment 19

[Wladimir Palant]

Nelson, this page shows up fine here (Firefox 3.0.5 and Minefield on Windows XP). Maybe one of your extensions inserts HTTP content into the page? Could you try starting Firefox in safe mode?

Comment 20

[Michael K]

(In reply to comment #19)
> Nelson, this page shows up fine here (Firefox 3.0.5 and Minefield on Windows
> XP). Maybe one of your extensions inserts HTTP content into the page? Could you
> try starting Firefox in safe mode?

Comment #8 confirms safe mode is still affected, and origonal report indicates that FF 3.0x is also unaffected.

**********
Others: Can you confirm that the pre-Beta 3 release corrects this?  I planned to install the released Beta 3 variant when it becomes available.

Comment 21

[Johnathan Nightingale [:johnath]]

(In reply to comment #17)
> Like Michael K, I have examined the pages, and find no http:// references 
> in them.  I also ran Johnathan's 3 javascripts and saw three alerts reporting
> zero found.
> 
> I think there is another bug for this problem, and that this like likely a 
> duplicate of that one.  I'll try to find it again.

Yeah, this sounds like bug 455367 then.

Comment 22

[Boris Zbarsky [:bzbarsky]]

Reopening.  This isn't about a case where we can't connect to the host; something else is going here.

Of course the relevant log isn't attached to this bug, like I asked it to be...  <sigh>.

Comment 23

[Boris Zbarsky [:bzbarsky]]

The relevant log file is https://bugzilla.mozilla.org/attachment.cgi?id=361451

Comment 24

[Honza Bambas (:mayhemer)]

This log is from trunk (FF 3.1b) I presume. Could we have also log from 1.9.1 (FF 3.0)?

Comment 25

[Honza Bambas (:mayhemer)]

We don't get security info for some of images:

0[825140]: SecureUI:896ec0: a5f4d4 571dca0 OnStateChange 10010 https://cfbillpay41.digitalinsight.com/images/FInal-mid.gif
0[825140]: SecureUI: GetSecurityState: - no nsITransportSecurityInfo for 0
0[825140]: SecureUI:896ec0: OnStateChange: subreq INSECURE
0[825140]: SecureUI:896ec0: UpdateSecurityState:  old-new  4 - 2

This happens just for a subset of all image requests. I would suspect some imglib code change here.

Boris, could you please create a new log with imgRequest:5 and nsHttp:5 too?

Comment 26

[Boris Zbarsky [:bzbarsky]]

It's not my log, but I bet Michael can do that.

ccing joe just in case.

Comment 27

[Nelson Bolyard (seldom reads bugmail)]

Does a 404 error response to an image load request on a secure page cause 
this?

Comment 28

[Honza Bambas (:mayhemer)]

Some images from the log that have security state are also not accessible (404). It's probably not the cause. BTW, it MUST not affect a security info presence.

Comment 29

[Boris Zbarsky [:bzbarsky]]

404 responses shouldn't cause the symptoms seen here (security info present but says the connection is insecure), if the 404 is coming via SSL.

Comment 30

[Jeff Muizelaar [:jrmuizel]]

Attachment: A full log of this problem for me

Here's a log (including imgRequest:5 and nsHttp:5) from the problem as it was showing up for me on pcfinancial.ca

Comment 31

[Johnathan Nightingale [:johnath]]

It's not clear to me if this is part of this bug, or a different one, but I can finally reproduce the behaviour Jeff was seeing, sort of.

STR for me:

1) Don't move the mouse
2) Visit https://www.txn.banking.pcfinancial.ca/a/authentication/preSignOn.ams?referid=loginBox_banking_go and let it load completely
3) It's currently secure, padlock is intact, larry is happy
4) Mouse over some of the menu items along the top (PC Points, Ways to bank, etc) to trigger the standard onmouseover hover feedback.
5) Page goes mixed content.

The code that handles the onmouseover looks like this:

function mOver(imgName) {
    var currentImage = eval("document.getElementById('" + imgName + "')");
    var imgSource = currentImage.src;
    var num = imgSource.indexOf("_off.gif");
    if (num > -1) {
        currentImage.src = imgSource.slice(0, num) + "_over.gif";
    }
}

which doesn't look like it should downgrade from https to http.

So anyhow - Jeff is going to attach the verbose log requested in comment 25, and he can still reproduce it without needing to mouseover, so it's possible there's a conflation of problems happening here, but I wanted to write the STR down somewhere, lest I forget them.

Comment 32

[Boris Zbarsky [:bzbarsky]]

The log from comment 30 doesn't show the nsSecureBrowserUI issues that Michael's log showed.  In particular, the only things that are marked as "INSECURE" in that log are in fact http:// URIs, and that log doesn't show us downgrading any pcfinancial.ca-related sites in the nsSecureBrowserUI code.

In other words, whatever Jeff is seeing is NOT what Michael is seeing.

Could we please just do one bug per steps to reproduce until we have some data indicating that the bugs are in fact the same instead of putting not-quite-related information in bug after bug?

Note that I believe we have existing issues with loads that happen after onload confusing security state.  Not sure whether those issues match comment 31.

Comment 33

[Honza Bambas (:mayhemer)]

(In reply to comment #32)
> Not sure whether those issues match comment 31.

Agree, it's different, drop in security in the first log appears during requests to https://cfbillpay41.digitalinsight.com/. It the secondary log there is no issue found and seems to reproduce a different scenario.

I'll wait for Michael to create his verbose log.

Comment 34

[Johnathan Nightingale [:johnath]]

Yeah, my bad. When I saw that Jeff was reproducing a similar-sounding bug, I asked him to put together a log on it, but I agree, one bug per bug.

Comment 35

[Michael K]

OK - reopened; cool.

Remember, I know much about this "sruff" but am no expert, thus:  What more can I do to assist; this problem still appears for me in Beta 2.

I understand Beta 3 has been delayed (due to unrelated Javascript issues), so there may be a chance to get this addressed, correct?

Direct me and I'll do my best to assist the experts in correcting this issue..

Comment 36

[Boris Zbarsky [:bzbarsky]]

Michael, can you do a log like you already did, but with:

  NSPR_LOG_MODULES=nsHttp:5,nsSecureBrowserUI:5,imgRequest:5

of the page that shows the problem for you and attach it to this bug?  That should help in correlating what the secure browser ui code sees with what the imagelib and http layers are doing.

Comment 37

[Michael K]

Attachment: Logfile from today (Feb 11, 2009)

Zipped to fit.

Comment 38

[Michael K]

(In reply to comment #36)
> Michael, can you do a log like you already did, but with:
> 
>   NSPR_LOG_MODULES=nsHttp:5,nsSecureBrowserUI:5,imgRequest:5
> 
> of the page that shows the problem for you and attach it to this bug?  That
> should help in correlating what the secure browser ui code sees with what the
> imagelib and http layers are doing.

Done! 

FWIW - Can anyone using Ubuntu 8.10 (Intrepid) make a BASH process so I can make these logfiles in Linux? The Mozilla page is on this procedure is outdated and I don't know enough to hack through to make a terminal application run like a Windows "CMD".  However, once I see how it's done, it can be another feather in my cap! :)  Thanks.

Comment 39

[Boris Zbarsky [:bzbarsky]]

Michael, when I try to unzip that file my unzip program says:

  Archive:  test.zip
   skipping: log021109.txt           unsupported compression method 98

Similarly, Gecko's built-in zip decompression library can't decompress it.

Would you mind compressing with a more commonly implemented zip compression algorithm?

Comment 40

[Honza Bambas (:mayhemer)]

Michael, thanks a lot, I can decompress the log, but you probably mistyped the name of imgRequest log module, make sure it is exactly "imgRequest:5" in the list, exactly as written in comment 36. I can't see the cause yet, I am missing the imgRequest logs.

Comment 41

[Honza Bambas (:mayhemer)]

It seems something is calling imgRequest::NotifyProxyListener before the channel even got OnStartRequest. imgRequest::NotifyProxyListener calls the consumer's OnStartRequets that gets to the security ui. security ui then tries to read the secinfo from the request but it is null at moment (the channel didn't get OnStartRequest yet where its mSecurityInfo is being filled).

Channel gets canceled with NS_BINDING_ABORTED sooner then gets OnStartRequets.

This is definitely caused by some change in libpr0n code, I don't know who should be cc'ed to get a clue.

Comment 42

[Boris Zbarsky [:bzbarsky]]

Joe is already cced, and he's your best bet.

Comment 43

[Honza Bambas (:mayhemer)]

Does this happen with 3.1b1?

Comment 44

[Joe Drew (not getting mail)]

I'm afraid without the imgRequest part of this log I can't diagnose it very well.

Comment 45

[Michael K]

Attachment: Feb 12 log, compression type 1

Comment 46

[Michael K]

Attachment: Feb 12 log, Compression type 2

Comment 47

[Michael K]

(In reply to comment #40)
> Michael, thanks a lot, I can decompress the log, but you probably mistyped the
> name of imgRequest log module, make sure it is exactly "imgRequest:5" in the
> list, exactly as written in comment 36. I can't see the cause yet, I am missing
> the imgRequest logs.

Here's my actual text file:

set NSPR_LOG_MODULES=nsHttp:5,nsSecureBrowserUI:5,imgRequest:5
set NSPR_LOG_FILE=C:\log021209.txt
cd \Program Files\Mozilla Firefox 3.1 Beta 2
firefox.exe

Sorry I was busy - took a while to get back into Windows for this test.

Comment 48

[Boris Zbarsky [:bzbarsky]]

Honza, imagelib doesn't enable logging in non-debug builds, so I doubt Michael can get you an imgRequest log.

If you want one, you need to change imagelib to force logging enabled.

Comment 49

[Honza Bambas (:mayhemer)]

I'm just thinking of a solution to this. Probably a build from try server?

Michael, would you be willing to do this ones again with a special build of firefox I would prepare for you? It is an install package, installing procedure is same as for normal firefox dist, same is uninstall.

Comment 50

[Michael K]

(In reply to comment #49)
> I'm just thinking of a solution to this. Probably a build from try server?
> 
> Michael, would you be willing to do this ones again with a special build of
> firefox I would prepare for you? It is an install package, installing procedure
> is same as for normal firefox dist, same is uninstall.


Yes, I can do this - I guess for simplicity sake, a Windows XP variant would be better.  Just don't code it so it steals all the money from my account!  :)  Email direct if needed: mrk-at-emarkay-dot-com.

Comment 51

[Honza Bambas (:mayhemer)]

(In reply to comment #50)
> Yes, I can do this - I guess for simplicity sake, a Windows XP variant would be
> better.  Just don't code it so it steals all the money from my account!  :) 
> Email direct if needed: mrk-at-emarkay-dot-com.

Thanks. I'm just preparing it, will post a link to an install package, say, not sooner then in 2 hours.

Comment 52

[Honza Bambas (:mayhemer)]

Joe: I was trying to create a try server build with this patch http://pastebin.com/m352fc45c but it produces a build that enables only some of imgRequestProxy logs, remaining logs are completely missing. What else to change to have build that enables libimg log?

Comment 53

[Honza Bambas (:mayhemer)]

Michael: sorry to take it that long time, finally I have a build that produces logs from all parts of imblib we need. You can the installer here: https://build.mozilla.org/tryserver-builds/2009-02-13_17:[e-mail]-forcelibimglog5/. It is based on firefox 3.1 b3pre.

Please install to some other directory then your current firefox installation is and reuse steps you describe in comment 47.

Thanks!

Comment 54

[Michael K]

Attachment: Feb 14 log, type1

using:
set NSPR_LOG_MODULES=nsHttp:5,nsSecureBrowserUI:5,imgRequest:5
set NSPR_LOG_FILE=C:\log021409.txt
cd \Program Files\Shiretoko
firefox.exe

Comment 55

[Michael K]

Attachment: Feb 14, type2

using:
set NSPR_LOG_MODULES=nsHttp:5,nsSecureBrowserUI:5,imgRequest:5
set NSPR_LOG_FILE=C:\log021409.txt
cd \Program Files\Shiretoko
firefox.exe

Comment 56

[Michael K]

Done - FWIW I like the "+" bar that moves to the left with the tabs.  While I have this "beta-beta" version working - any other things I can do to assist?

Comment 57

[Boris Zbarsky [:bzbarsky]]

OK, here's the relevant part of that log:

0[829140]: 722786 [this=38cd840] imgRequest::RemoveProxy (proxy=3d0ef10) {ENTER}
0[829140]: 722786 [this=38cd840] imgRequest::GetURI
0[829140]: 722786 [this=3d0ef10] imgRequestProxy::OnStopRequest (name="https://cfbillpay41.digitalinsight.com/images/FInal-mid.gif")
0[829140]: SecureUI:4b018e0: OnStateChange: progress: for something else
0[829140]: SecureUI:4b018e0: OnStateChange
0[829140]: 722786 [this=38cd840] imgRequest::GetURI
0[829140]: SecureUI:4b018e0: a51e34 3d0ef10 OnStateChange 10010 https://cfbillpay41.digitalinsight.com/images/FInal-mid.gif
0[829140]: 722786 [this=38cd840] imgRequest::GetSecurityInfo
0[829140]: 722786 [this=38cd840] imgRequest::GetURI
0[829140]: SecureUI: GetSecurityState: - no nsITransportSecurityInfo for 0
0[829140]: SecureUI:4b018e0: OnStateChange: subreq INSECURE
0[829140]: SecureUI:4b018e0: UpdateSecurityState:  old-new  4 - 2

Looks like imagelib is helpfully sending all possible notifications when an imgRequestProxy is going away, and we get confused by that here.  Since we're assuming that it's already seen data, we proceed to look at its security state, etc.

I would bet money that imagelib is violating the various necko contracts involved here, but that's not particularly suprising...

Comment 58

[Honza Bambas (:mayhemer)]

Michael, thanks. It worked. Please stay tuned, I am not very wise from the log, yet, but I hope I get further soon.

So far, the problem is that the image request proxy is almost immediately canceled after it has been started. It seems to be canceled from nsImageLoadingContent::LoadImage. The clue is that it is always followed by a new image load.

Just guess.. could that be cause by this change? There is image request cancel added, landed 5 days before this bug was reported: http://hg.mozilla.org/mozilla-central/diff/bfcbbaa6d2c7/content/base/src/nsImageLoadingContent.cpp

Comment 59

[Honza Bambas (:mayhemer)]

0[829140]: 722489 [this=3d0ef10] imgRequestProxy::Cancel {ENTER}
0[829140]: 722489 [this=3d0ef10] imgRequestProxy::Cancel {EXIT}
0[829140]: 722489 [this=19225c0] imgLoader::LoadImage (aURI="https://cfbillpay41.digitalinsight.com/cwp411/build/static/generic/images/recur-pmt-mid.gif?cfwver=20090121_0839-CFWEB411") {ENTER}


3d0ef10 is the proxy created few lines above for /images/FInal-mid.gif

Comment 60

[Boris Zbarsky [:bzbarsky]]

Honza, the change you point to only affects <img src="">.

This bug would have more to to with the security UI tracking image loads at all, no?

Comment 61

[Honza Bambas (:mayhemer)]

(In reply to comment #60)
> Honza, the change you point to only affects <img src="">.
> 

And why shouldn't it be related to the problem we have here?

> This bug would have more to to with the security UI tracking image loads at
> all, no?

I wouldn't say so, but I believe patch for bug 455367 will fix the symptoms. The problem I see in the log is that the image proxy is canceled (probably from one of nsImageLoadingContent::LoadImage overloads - but I claim this just because I so far could not find another place where this could happen) before the underlying http channel get its OnStartRequest call from the transaction. While the proxy is being canceled it calls OnStartRequest to its listener that bubbles to SecUI. There is still a link to the channel but it didn't load security info from the http connection yet -> secUI doesn't get the sec info.

I want to figure out why the image proxy gets canceled while it has not to be. It is not IMO related to 404 code that the channels gets later.

Comment 62

[Boris Zbarsky [:bzbarsky]]

> And why shouldn't it be related to the problem we have here?

Becase in this case we're taking an <img> that used to point to https://cfbillpay41.digitalinsight.com/images/FInal-mid.gif and pointing it to https://cfbillpay41.digitalinsight.com/cwp411/build/static/generic/images/recur-pmt-mid.gif?cfwver=20090121_0839-CFWEB411 per comment 59?

> the image proxy is canceled ... before
> the underlying http channel get its OnStartRequest

THat's fine so far.

> While the proxy is being canceled it calls OnStartRequest to its listener that
> bubbles to SecUI.

Right.  This is really no different from the case when necko just couldn't connect to the server at all, from the point of view of all of the layers above necko, right?

> I want to figure out why the image proxy gets canceled while it has not to be.

It's canceled because the page changes the src attribute of an <img>, as far as I can tell.  When that happens, we cancel the old request and start a new one for the new src value.  That's expected behavior in that situation.

Comment 63

[Honza Bambas (:mayhemer)]

I agree with all. Bug 455367 is then duplicate of this, because this is just another effect of missing libimg notifications and violations.

I have wrote an automated test for this and I can confirm that patch from bug 455367 fixes this bug too.

Comment 64

[Boris Zbarsky [:bzbarsky]]

Awesome.  Want to attach the test?  We'll want to land it when we land the fix.  I guess you can attach to either bug.

Comment 65

[Honza Bambas (:mayhemer)]

I will attach it to bug 452401 (tests for mixed content dedicated bug) and land it when tree reopen.

Comment 66

[Boris Zbarsky [:bzbarsky]]

OK.  Landed bug 455367.  I guess we should re-mark this duplicate after all.

Comment 67

[Michael K]

Confirmed that in Beta 3 this has been FIXED!  Thank you!