209308 - Blocking of images still loads them - it just doesn't display them

Status: RESOLVED INVALID

(Core :: Graphics: Image Blocking, defect)

Description

[Scott Dunbar]

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4b) Gecko/20030513
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4b) Gecko/20030513

When "Block images from this server" is enabled for a server the server is still
contacted and the image is downloaded but it isn't displayed.  This allows
cookies and web bugs to still be used.  My guess is that this is done to
determine the width and height of the image to reserve that space on the page if
it isn't specified in the img tag.

Reproducible: Always

Steps to Reproduce:
1. Block images from a site
2. Go to a page that loads images from that site
3. The status bar / a network sniffer / live HTTP Headers from mozdev.org all
show that the image is actually being loaded from the network.

Actual Results:  
The page rendered correctly but the images were still loaded from a server that
I didn't want.

Expected Results:  
I feel that a blocked site is a blocked site.  It should never be contacted.  If
the page renders wierd then so be it.  This issue appears to exist in the mail
client too.  I still think that the old interface that asked you if you wanted
to load images from a site with a dialog was better.  The new way makes it very
difficult to block web bugs.  Is that because AOL *wants* web bugs to work? 
Pointless ranting aside, a blocked site should never be contacted.

Comment 1

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

I tried it on this very page, and with shift-reload only show_bug.cgi and
edit_bug.css are retrieved from the network (according to ethereal). The header
image is not. Is this still a problem with the latests nightlies?

Comment 2

[Scott Dunbar]

Ok, I'd swear that I got this to happen but I be darned if I can reproduce it
now.  Sorry for the bother.  I'll keep testing and if I figure out what I did
I'll reopen or enter a new bug.