Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090511 Shiretoko/3.5b5pre ID:20090511031352 Using the following steps the EV button of the given secure site is not sticky. It flashes for a second and is removed afterward. The user is confronted with a broken lock icon in the status bar and no identity information at all. Steps: 1. Open http://www.paypal.de 2. Click on the link called "Sicherheit" at the top of the page 3. Reload the page Doing step 2 the EV button is visible for under a second and is removed again. With step 3 the EV button is shown again and contains all identity information now. This behavior doesn't happen when you directly open the target url (https://www.paypal.com/de/cgi-bin/webscr?cmd=xpt/Marketing/general/SecurityAtPayPal-outside). Could this happen due to a redirect? But why it only happens once? This is a regression against Firefox 3.0.x. Asking for blocking 1.9.1.

Probably similar to bug 450912. Raw regression range is 080901 - 080905. I'll come up with more details soon.

Regression window: 08090102 - 08090204 Checkins: http://tinyurl.com/ot7vy4 Probably related bugs: Bug 450912: secure sites appear with broken lock icon, resource:// incorrectly treated as insecure Bug 135007, Transfer mode of images should be relevant for shown lock icon state (mixed content) Based on ideas from Stuart Parmenter and experimental code from Kai Engert Patch contributed by Honza Bambas

For what it's worth, anyone with a nightly can create this sort of log... Here's the key part: -1601624288[80a5c0]: SecureUI:1d0d9aa0: 1d050474 18f1db60 OnStateChange 10010 http://paypal.112.2o7.net/b/ss/paypalglobal/1/H.19.3/s49484177881599?AQB=1&ndh=1&t=11/4/2009%2010%3A38%3A3%201%20240&ce=UTF-8&ns=paypal&pageName=SRD%3A%20Main%20Home&g=http%3A//www.paypal.de/de&cc=USD&c16=SRD%3A%20Main%20Home%3Alogin_form%3A%28No%20Data%20Entered%29&c30=712&c31=78%25&c47=srd%3A%20main%20home&s=1920x1200&c=24&j=1.7&v=Y&k=Y&bw=1140&bh=712&p=Test%20Plug-in%3BDefault%20Plugin%3BWebEx%20General%20Plugin%20Container%3BiPhotoPhotocast%3BDivX%20Web%20Player%3BFlip4Mac%20Windows%20Media%20Plugin%202.2.1%3BShockwave%20Flash%3BQuickTime%20Plug-in%207.6%3B&pe=lnk_o&pev2=Form%20Analysis&pid=SRD%3A%20Main%20Home&pidt=1&oid=https%3A//www.paypal.com/de/cgi-bin/webscr%3Fcmd%3Dxpt/Marketing/general/SecurityAtPayPal-outside&ot=A&AQE=1 -1601624288[80a5c0]: SecureUI:1d0d9aa0: OnStateChange: 1 STOP IS_REQUEST -- -1601624288[80a5c0]: SecureUI: GetSecurityState: - no nsITransportSecurityInfo for 0 -1601624288[80a5c0]: SecureUI:1d0d9aa0: OnStateChange: subreq INSECURE -1601624288[80a5c0]: SecureUI:1d0d9aa0: UpdateSecurityState: old-new 4 - 2

That http URI is a 2x2 pixel image. So this "regressed" when bug 135007 landed, but the new behavior is in fact correct: the page is loading an insecure image.

OK. So here's the stack to the relevant LoadImage() call, with some stuff elided: #3 0x1328415e in nsImageLoadingContent::LoadImage ... #11 0x002df8d0 in js_Interpret ... #15 0x134e8000 in nsJSContext::CallEventHandler ... #22 0x12f641ac in DocumentViewerImpl::PageHide So basically, there's an unload handler on the front page that starts an insecure image load (user tracking, basically). This load is treated as part of the load of the new page, and leads to the observed behavior. Ideally we would ignore this new load for purposes of the SSL state of the new page. Or not allow it to happen at all (likely breaking omniture's data-gathering in this case). Or something.

Can't see us blocking on this at this time, might reconsider if we find it's causing problems for major sites.

Ok, so this image is loaded via javascript. Is that the reason why it is not shown in the media tab inside the page info window? Further why it only happens once? After a reload we simulate a secure connection while we don't have one? Does it happen because we use the image from the cache? As what I can see the Javascript code which puts this image onto the page is executed on each reload.

> Is that the reason why it is not shown in the media tab inside the page info > window? It's not shown there because the relevant image element is not in the new document. It was never in any document, in fact. > Further why it only happens once? The image load is started by the http://www.paypal.de/ page. If you're not leaving that page, that image load doesn't happen. > As what I can see the Javascript code which puts this image > onto the page is executed on each reload. I think you need to read comment 5 more carefully...

I saw a similar issue on a website where a donation can be made using paypal. If you go to https://www.miroguide.com/donate and click the donation link, you get redirected to https://www.paypal.com, but then paypal shows an image coming from the miro domain on http and the EV button disappears. I tried the paypal.de and miro test with Chrome, Opera 10 and IE 8, and they seem to match Firefox new behavior: Chrome shows a warning icon with "This page contains insecure elements". Opera 10 shows a question mark instead of the padlock icon. IE8 doesn't show the padlock icon, and on the miro donation test it shows a security warning message box.

Comment 9 has nothing to do with this bug. In that case the https page is just linking to a non-https resource, so we correctly drop the "secure page" styling. As you noticed, so does every single other browser. That's because the site is in fact insecure. Feel free to report that to paypal and/or miro, of course.

my bad, sorry. Missed the part where an insecure image is loaded from an unload handler in the parent page. data:text/html,<body onunload="document.getElementById('img').src='http://www.mozilla.org/images/feature-logos1.png'"><img id=img src=about:blank><a href=https://bugzilla.mozilla.org/>bugzilla</a> Note that Opera 10 and IE 8 suffer from the same issue (but the testcase above doesn't trigger the issue on IE 8, so the paypal page may be doing things a bit differently). Chrome doesn't have the issue.

Boris, so shall we better close this bug? Due to we behave correctly and it is a problem on the website we will not do anything on it, right?

I don't think our behavior here is correct. See comment 5.

(In reply to comment #13) > I don't think our behavior here is correct. See comment 5. Updating the summary to reflect that, in the hopes of avoiding more cross-talk.

Requesting wanted1.9.2? - this style of loading images in onunload is pretty common on the web. One major example is embedded google maps, which appear in countless places. (The testcase I added in bug 519776 was reduced from such an embedded google map.) Any secure site opened from a page using google maps will now appear insecure.

This clearly looks like a duplicate of or quit related to bug 506008.

It might not be, depending on how that other bug is fixed.

Hello all. Similar to bug 552789 reported in March 2010. https://bugzilla.mozilla.org/show_bug.cgi?id=552789

Is bug 716620 also another mutation of this bug?

This is even happening if you open another page in the same browser tab by inputting its url manually. There is nothing wrong with the new page but it gets reported as insecure. They only way to avoid it is to request your customers to always open the page in a new tab (given the widespread use of unload handlers in tracking). This bug can also be seen in the firebug network tab as it associates the request on unload with the new page. I always thought that was a glitch of firebug. Any idea when this could be handled?

This bug looks like a duplicate of bug 947079, which was fixed in Firefox 39.