215012 - image still loads when images from this server are blocked (nsIContentPolicy)

Status: NEW

(Core :: Graphics: Image Blocking, defect)

Description

[Matthew M. Boedicker]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030803 Mozilla Firebird/0.6.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030803 Mozilla Firebird/0.6.1

I have blocked images from m.doubleclick.net (and verified that "Block Images
from m.doubleclick.net" is checked in the right-click menu), but this image is
still displayed in the browser.

Reproducible: Always

Steps to Reproduce:
1. Load the URL http://m.doubleclick.net/viewad/865417/2_control_728x90.gif.
2. Right click on the images and select "Block Images from m.doubleclick.net"
3. Reload the image.

Actual Results:  
The image is reloaded and displayed in the browser.

Expected Results:  
A blank page should have been displayed in the browser (the image should not
have been shown).

When this image is in the context of a page (and not being viewed by itself) it
also displays when it should be blocked.

Comment 1

[Oliver Klee]

Confirming on 2003080304 WinXP.

Comment 2

[Kai de Leeuw]

isn't this the correct behaviour?

if you have blocked pictures from a site, and you choose "view image" from the
right click context menu, you can load that image anyways.

loading an image by itself, isn't that the same thing as "view image"?

once the image has been loaded one time by either "view image" or loading the
image by itself, it is in the cache, and then maybe it is no wonder that it
appears in the page.

Comment 3

[Matthew M. Boedicker]

The page this image was originally found in is http://drudgereport.com. When I
load this page, block the image, then clear the cache and reload the page, the
image is still displayed.

I am not sure whether image blocking takes into account whether the image is
cached or not. It seems like it should show or block the image based on the URL
only, and not the cache status.

Comment 4

[Michiel van Leeuwen (email: mvl+moz@)]

This works for me. I can block the image when using the url:

data:text/html;charset=utf-8,%3Chtml%3E%3Cbody%3E%3Cimg%20src%3D%22http%3A%2F%2Fm.doubleclick.net%2Fviewad%2F865417%2F2_control_728x90.gif%22%3E%3C%2Fbody%3E%3C%2Fhtml%3E%0D%0A

That is, a page with a link to the image. Only viewing the image will always be
allowed.

Comment 5

[Matthew M. Boedicker]

I can also block the image when it is loaded in a test page. I believe the
reason it is not blocked by http://drudgereport.com is that that page loads the
image using an alternate URL, which redirects (twice) using http 302 (Moved
Temporarily) to the real image URL. So I am guessing the image blocking kicks in
when parsing the html source, and not when issuing the HTTP get requests.

Comment 6

[Boris Zbarsky [:bzbarsky]]

It kicks in when issuing the initial GET, but not on the redirects.

Comment 7

[Tim]

I have some updates that will result in a second pass (through ShouldProcess) of
images with the post-redirect URI.  These changes are bundled among other
updates in bug 191839.  Note that for now, intermediate redirects will not go
through content policy, since they are handled in places we don't want content
policy dependencies.  I have updates to the image manager (which deals with
permissions) to take advantage of this change.

I don't intend to split off pieces of the patch for this bug, so this will
become fixed once bug 191839 lands a patch.

Taking, since I'm essentially working on it.

Comment 8

[Tim]

Really reassigning.

Comment 9

[Oliver Klee]

Setting dependency.

Comment 10

[Boris Zbarsky [:bzbarsky]]

darin, does it make sense to make redirects call content policy?  Otherwise all
callers of content policy have to install onredirect listeners...

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

oh, would that allow fixing bug 248052?

Comment 12

[Darin Fisher]

(In reply to comment #10)
> darin, does it make sense to make redirects call content policy?  Otherwise all
> callers of content policy have to install onredirect listeners...

what would the aContentType parameter be though?  would be nice if aContentType
was actually a bit field in which the type is expressed as well as some flags...
e.g., a meta refresh flag or a http redirect flag.  currently, i think meta
refresh is mutually exclusive with other types, which seems odd (subdocument vs.
document).

as for hooking into content policy, maybe we need a system for registering
global nsIHttpEventSink objects that can intercept OnRedirect.  we just need to
make sure there is enough context available from nsIHttpChannel to turn the
OnRedirect into a call to ShouldLoad, right?

Basically, I think I'm saying that I don't want necko to directly depend on
nsIContentPolicy ;-)

Comment 13

[Tim]

-> new / default owner, until I get more time.

Comment 14

[Boris Zbarsky [:bzbarsky]]

I suspect that the asyncOpen2 work likely fixes this, since we now do content policy checks inside necko, on every channel.