There really should be four Image Acceptance Policy options: NEVER load images, ALWAYS load images, load images ONLY IF site allowed, and load images UNLESS site blocked. If the third of these existed, then I wouldn't mind bug 110112 not being fixed (or only being "fixed" by the removal of the "Ask me before downloading an image" option).

Actually you could cut that down to 3 options without doing any harm: A) Allow Images (Unless Blocked) B) Block Images (Unless Allowed) C) Text Only (for usability testing and Lynx nostalgia) By the way, does the Image permission setting include other tags with SRC attributes, such as SCRIPTs and OBJECTs? I bet 99% of web users consider Flash movies to be "images", and I absolutely detest 3rd party javascripts.

This is a duplicate. Please find the original.

Are you sure this is a dupe? I just went through the enhancement requests for "image blocking" and couldn't find any repeats. (This is not the same as the fix/reintroduction of the "ask before loading images" option, though some of the comments crossover.) Thanks for the summary rewrite, btw - "whitelist" explains it much more clearly! And I agree that Flash, etc. should be treated as an image - it's hard to imagine someone wanting to block images from a site but wanting Flash.

See also bug 82734, same bug for cookies.

In Mozilla 1.1, there is still support for maintaining a list of sites that are "allowed to load images", but unless I'm missing something that list is NEVER consulted now...

I'll vote for this too. While it's kind of good to be able to block remote images, this prevents many HTML newsletters from being useful. I think an image whitelist would complete it, perhaps with a question the first time "This message refers to images from <url>. This can be used to track when you open email messages. Do you want to load these images? [Yes] [No] [ ] Don't ask me again

BTW, There are two reasons for blocking images in mail: 1) Blocking ad sites This is addressed by blacklists, but could also probably be done by whitelists. 2) Preventing tracking of email being read This is addressed by whitelists.

*** Bug 185006 has been marked as a duplicate of this bug. ***

Mass reassigning of Image manager bugs to mstoltz@netscape.com, and futuring. Most of these bugs are enhancement requests or are otherwise low priority at this time.

This is not really an enhancement request, I think it's more of a bugfix. Consider that we currently have an image permissions list to which "site can load images" entries can be added, despite the fact that said entries are NEVER used, anywhere... There's something not right there, surely.

duping this to 75915 since the backend and UI requirements are pretty much identical.

*** This bug has been marked as a duplicate of 75915 ***

I disagree somewhat with duping this, since each of the various blockers/managers is considered a separate component. Perhaps set it as a dependency instead? If we leave this as a dupe, then the summary, component, and other aspects of bug 75915 will need to increase in scope.

The requirements for this may be nearly identical to bug 75915, but this is still a different feature. In particular, with cookies there is an "ask me before storing a cookie" option, which effectively gives you a cookie whitelist (if you're prepared to be asked about cookies on each new site). That option is not available for images (it used to be available, but was removed, see bug 146513). Also, if this were to be duped to 75915, then 75915 should be modified so it covers images as well as cookies.

*** Bug 209454 has been marked as a duplicate of this bug. ***

updating summary (from bug 209454)

*** Bug 234366 has been marked as a duplicate of this bug. ***

This was done in bug 184059 You can set your prefs to block, add sites to the list, and have a whitelist. *** This bug has been marked as a duplicate of 184059 ***

v