User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040517 Firefox/0.8.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040517 Firefox/0.8.0+ blocking images from a site no longer blocks background images. this is a regression. Reproducible: Always Steps to Reproduce: 1. visit http://mozillazine.org/ 2. block images from the site 3. refresh Actual Results: background images are rendered (page header) Expected Results: blocked all images.

mvl, this broke when the content policy patch landed... any idea what's up here?

A quick printf told me that nsImgManager is still called. It alse returns rejected. A stack then told me that the image was loading from css. http://lxr.mozilla.org/seamonkey/source/content/html/style/src/nsCSSValue.cpp#378 uses NS_SUCCEEDED(CanLoadImage()), while CanLoadImage() now returns a bool. So that should just be |if (mURI && CanLoadImage())|

Yup, seems to do the trick.

Re: bug 236919 comment 15 - I've double checked and the first Firefox build to show this issue is definitely 20040515 (confirmed from file date and from about:), but like you say it shows up in Mozilla on 20040514 so I don't know what's going on there.

Comment on attachment 148761 [details] [diff] [review] update to new return value Oh, duh. And I even looked at this code... Can you also pass aDocument for the context here? r=bzbarsky with that.

Comment on attachment 148761 [details] [diff] [review] update to new return value er, sr=bzbarsky too. ;)

you mean to make the call |nsContentUtils::CanLoadImage(mURI, aDocument, aDocument))| ?

Yep. Exactly.

Since trunk is freezing for 1.8a in a few hours, I took the liberty of checking the patch in, with the change I asked for (which should fix mailnews blocking of background images).