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.
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?
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.