Closed Bug 492358 Opened 12 years ago Closed 6 years ago

Loads triggered on unload incorrectly counted against next load's security state


(Core Graveyard :: Security: UI, defect)

Not set


(Not tracked)



(Reporter: whimboo, Unassigned)


(Blocks 2 open bugs, )


(Keywords: regression, Whiteboard: [psm-padlock])


(1 file)

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.

1. Open
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 (

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.
Flags: blocking1.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

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
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.
Blocks: 135007
Can't see us blocking on this at this time, might reconsider if we find it's causing problems for major sites.
Flags: blocking1.9.2?
Flags: blocking1.9.1?
Flags: blocking1.9.1-
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 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 and click the donation link, you get redirected to, but then paypal shows an image coming from the miro domain on http and the EV button disappears.

I tried the 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=''"><img id=img src=about:blank><a href=>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.
Summary: Secure site appears with broken lock icon on first load (EV button not sticky) → Loads triggered on unload incorrectly counted against next load's security state
Flags: blocking1.9.2? → blocking1.9.2-
Blocks: lockicon
Duplicate of this bug: 519776
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.
Flags: wanted1.9.2?
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.
Depends on: 506008
Hello all. Similar to bug 552789 reported in March 2010.
Assignee: kaie → nobody
Whiteboard: [psm-padlock]
Duplicate of this bug: 723580
Is bug 716620 also another mutation of this bug?
Blocks: 961457
Duplicate of this bug: 973342
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?
Duplicate of this bug: 1093300
Blocks: 1093300
This bug looks like a duplicate of bug 947079, which was fixed in Firefox 39.
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 947079
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.