Image confirmation was removed to "fix" bug 110112. In closing bug 110112 waterson@netscape.com said: --- If you'd like to implement this feature properly, here's what to do. 1. For each image that is being loaded, check to see if it has been allowed, denied, or if the user must intervene. If the image is allowed to load, load it. If the image may not be loaded, do nothing (i.e., don't issue a load request). 2. If the user must intervene, do the same thing you do in the `deny' case, but place the image's URL on a queue, and return out to the main event loop. (The important thing is to _not_ nest an event loop while doing frame construction or reflow!) 3. At some later point, process the queue. This could be done in any number of ways. You could post an event in (2) that would bring up the same crappy dialog that was popping up before (which would be insanely stupid from a design point of view). Or, you could bring up a `image manager' dialog that lists all the pending image loads and lets a user accept or deny each individually. Go nuts. design an ultra geeky UI that lets you organize the image loads into a tree by source URL. Or by page loading them. Have a `deny all' button. Whatever. 4. When a user decides to `accept' an image, queue the image load. Now, _I_ am not going to implement this, as I find this feature to be inane. ---

-> XPApps. This is not a core layout feature.

Correct, this is an image blocking function.

All/All

If the "ask me before downloading an image" option has been disabled, my understanding of the image handling logic is that the image permissions list will never be consulted, because none of the remaining acceptance options use it... So has the entire image manager been removed, or are we left with a kind of "appendix" - support for maintaining a list of site-specific image permissions which are never actually used? I don't actually care about the "ask me" option per se (though I'd hardly describe it as inane), but I really do want the image permissions list to be consulted and, as far as I can tell, there's no way to get that to happen without enabling "ask me". But I could be missing something very obvious - please let me know if there is some way to do this!

While I am not an authority, it is my experience that it is still possible to block images. Right click the image in question and select "Block Images from this Server". Doing so does add the site to the cookperm.txt file. However, this method is sub-optimal because you must first determine the source of that image (page info or image properties context) before you can block it. Another situation where this method is not adequate, is it attempting to block the 1x1 tracking images. Bug 110075 requests the ability to do image confirmation from the page info -> media tab. Bug 110093 extends that by adding an icon to reflect a site's state in cookperm.txt.

It half works. If I set "Accept all images", then that actually means "Accept all images unless site blocked". But if I set "Do not load any images", then no images are loaded ever, not even from sites "allowed" under image permissions. That means that (sans the "ask for permission" option) there is no point ever marking a site as "allowed to load images", because that information will never be used... Should I file a separate request for an option "Do not load images unless site is allowed" (or for that to be how "Do not load any images" is interpreted)?

Does anyone remember AtGuard? Excellent utility, ahead of its time and the unfortunate orphan of WRQ, adopted and ruined by Symantec. Anyway, one of its tab in the settings module was "Web", and it built a list of sites based on web traffic passing through certain ports (user-definable but the defaults were 80,8000,8080,81). It had a popup asking for permission to allow or block cookies/ javascript from either the site or domain. Based on what you answer, it adds to the list that site or domain and the associated permissions. It did parsing (probably simple substring searches) on incoming HTTP streams for keywords, too; this blocked ads by matching up pending connections with a block list. Pretty powerful. It's where I *thought* Mozilla was going with its privacy features. It seems as if the related team has lost its way on where to go with this. I think approaching AtGuard's functionality is a worthy goal.

francis_uy@yahoo.com wrote: Please add your comment (and your vote) to bug 146513, and ask your friends to do the same. So I shall (at least the first part): > *sigh* yeah, I know I should probably add this to bugzilla, but do I dare > tempt the wrath? I used this a lot. It's the best way I've seen to avoid > those nasty advertisments. This r/click thing means I have to let it > download once before I can block it, and that means that all those nice > little 1x1 images get to invade my webmail and browsing undetected. Why > open up more security holes? I haven't had -any- problems with it > crashing, even after multiple requests, except with a few sites (like > rcm.images.amazon.com) where direct to the sites produces a 404. *bigsigh* > > It was one of the things I recommended mozilla -because- of.

I have filed a separate enhancement request (bug 145690) for support for an image whitelist. That was part of the functionality of the "image confirmation" feature that was removed in closing bug 110112 (the other part is the popup confirmation itself, which is covered by this bug).

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

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

The image handling in Mozilla is still broken for my purposes - inferior to that of Konqueror, Netscape 4, or even Netscape 3. I want to load images only on a minority of sites, perhaps 10 or 20 percent. (Basically those sites which are unusable without images, plus a few that have photos or maps that I actually want to see.) This doesn't seem like an unusual thing to want - anyone on a slow modem, or paying high bandwidth charges, must surely consider something like that. At the moment I have the following options with Mozilla. 1) I can set "accept all images" or "accept images that come from the originating server" and manually add images sites to the block list. But I can only do that _after_ I've already viewed the page and downloaded the images on it. 2) I can set "don't load any images", in which case there's no way to load images at all - adding sites to the "allow sites" list does nothing, nor is there any "load images" button as there is in Netscape and Konqueror. 3) I can set "ask me before downloading an image", in which case images are loaded iff they are in the "allowed list", but I have to put up with popup "do you want to allow images from X" messages AND Mozilla crashes regularly. I've been putting up with the regular crashes for the last half year (this rant inspired by two in quick succession), but it's really getting me down. Any of the following would make me really happy: A) a fix to this bug, so the crashes stop B) addition of a "load images" button - bug 57505 - so I can load images on a page/session basis C) proper whitelist support - bug 145690 - so I don't have to deal with popup queries and can add sites to the "allowed" list as necessary. This is my preferred solution, and is probably the easiest to implement - it might even be a single if statement somewhere that needs modification. And that's been marked for 1.2alpha, so I'm hopeful! In every other respect, Mozilla blows all the other GUI browsers I've tried away, so the image handling problems are frustrating!

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

A lot of votes for something that isn't going to happen, as it seems: 1) "_I_ am not going to implement this, as I find this feature to be inane" 2) assigned to nobody@mozilla.org 3) status whiteboard is set to "WONTFIX?" I wonder if Netscape management allows employees to re-implement this feature? Actually, it's really sad to see it go away. Do votes count? note: I vote for reimplementation of this nice feature. Please don't ask me to do it or try to be funny and assign it to me :-)

Would something like this work for you?

I can only really speak for myself, but I think the point of this request is to control whether images load at the time the page is *loaded* rather than *after* they have already loaded once. Using the image manager only allows you to control the images after they have already loaded and potentially already done their damage. This is important to prevent webbugs from loading when reading web-based email which may "confirm" an email address for some spammer out there. As far as I can tell, the proposed "geeky" UI doesn't allow for this behavior.

I could do without this bugfix, IF I had the option to block all images EXCEPT those in the image manager's "allow" list - ie, image whitelisting ala bug 145690. Unfortunately that seems to have been scheduled for implementation in 1.4, which I'm guessing is a shorthand for "probably never". For code-cleanup purposes, I'd just like to point out that if the "ask before loading images" feature is removed, then the image manager's "site can load images" entries are NEVER consulted... so support for them should be removed completely (unless bug 145690 is going to be fixed sometime). BTW, is this bug is only affecting users of the X11 version?

To answer question in #17, I use Mozilla on both Windows and Unix, and this bug causes Mozilla to crash only under X11. For my usage pattern, being able to answer which images to load as the page is loaded is incredibly useful and the main reason why I use Mozilla. (I read a small number of sites regularly, and a relatively large number only once or twice, when someone sends me a link to an item of interest or following up on a search engine recommendation.) It's also the reason why I haven't upgraded Mozilla, and am not planning to, to a version where this has been disabled. Now, to comment #15 and the proposed UI: is this the idea for an implementation of step 3 in the "proper way to implement this feature"? Or something that comes up *after* images have been loaded? I think the "geeky" interface to image blocking could look similar to this even in the first case, with the obvious exception that you wouldn't see the image since the dialog would come up before any loading.

The "fix" for bug 110112 is the very reason I am using mozilla 1.0.1 build 20020808 for everyday use and do not plan to upgrade. This is the last build with image blocking confirmation. As I am in mozilla.org Tech Evangelism team (responsible for Central Europe), the fact that I have to keep a separate fresh build for QA work, just because someone had withdrawn one of the most usefule features makes me very sad/angry/pissed_off (all at the same time).

This is about control. Who should control my computer. It seems that every corporation out there wants to take control of my computer. Microsoft was first, with changing file type program assignments without asking, then came quicken, where they changed peoples home page, then we have DoubleClick with thier ubiquious cookie. I want control of my computer. I want to control what images, frames, plugin content, email html, javascript, java, etc. etc. loads/runs on my computer. (Why frames? Some ad folks are getting sneaky and using a frame for thier banner instead of just an image, so you get a hit there even if you never load the image. Therefore I would also like to see a "Load frame contents only from base server...") I want to restrict this content to only sites I want to receive content from. I would love it if Mozilla could provide this. From my experience it is the closest. Perhaps we need a Trusted Mozilla version that has all the security we can stand. Anyone interested? I can't code worth ****. (and OO programing is a complete mystery to me...)

A recent comment in bug 110112 that describes a very complete UI for image blocking: -------------------------------------------------------------------------- Sead Dowd (ssdowd@yahoo.com) wrote on 2002-08-27 10:30: How about popping up a single dialog box that has a list of all the image sites referenced by the current page (at least those not already blocked or approved) with a block/allow (remember) line item next to each one? Then leave the dialog open until all images are loaded/blocked. This would allow only one dialog box per page, but it would stay open until all images have been filtered. Something like this: Images on this page: Allow: ( )All ( )None (x)Selective (enables list below) Site Allow/Disallow Remember Images on Page ===================================================================== www.cnn.com (x)Allow ( )Disallow [x] 13(details) ads.doubleclick.net ( )Allow (x)Disallow [x] 2(details) cnn.com (x)Allow ( )Disallow [ ] 10(details) (OK) (Disabled until all sites have a selection for Allow/Disallow) Selecting All or None would take the action and dismiss the dialog. Details would list the images for that site.

Great idea - that sounds like a nice interface to me! The list might have to be a little bit dynamic (grow as the page is being loaded, as frames are referenced, etc.) - but this should still be simpler than handling multiple dialog boxes. For completeness I would probably prefer all the images to be listed - those already blocked or accepted shown as such. We could highlight those not yet selected in a different color if need be.

Re: #21 Fantastic! But why would it need to remain open? Once the information is loaded into the box and the 'okay' button has been clicked, the box should go away and let the program do its thing. :) I'm still using 2002043010 because I was assured image confirmation had been disabled in the nightlies when I normally would have upgraded. :/ Image confirmation is very important to me, and this single dialogue idea would be a god-send. (Thanks in advance, ye programming gods. ;)

PS I would -love- to upgrade to the newest mozzy, but until image confirmation is re-enabled on a -before-downloading- basis, I can't/won't.

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

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

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

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

just putting in an additional plea to restore this feature. this is, for me, the single feature that most made mozilla stand out from other browsers. i'd rather have prompting to block images back; the occasional crash is a small price to pay! as others have said, the "right-click to block images" is a poor alternative because you can't block web bugs, and you can't see what site you're blocking without taking additional steps. please put it back - even if it's not listed in the GUI preferences, give us a toggle in prefs.js for it... that way those of us who care strongly enough can use that to enable it, and the rest of the world that doesn't use it won't be affected by it.

I would also like to see the confirmation dialog back really soon. I am still using 1.0 because it seems to be missing in all the other newer releases. I will not upgrade until it's back.

Ditto for reasons I want it fixed. Also I like the uber image UI idea.

Look. If people want this, someone is going to have to do it. They can follow the nice instructions that waterson provided. Convenient, huh? The point is, this hypothetical someone will need to be interested in implementing this, whether for the fun or for the money. This is an open-source project -- people get to pick what they want to work on, unless their employer picks for them. Whining in a bug is not an effective way to convince people that they should do something they find unpleasant -- it's not going to work. If people want this to happen, they need to find someone (themselves, perhaps) to implement it. It's a social problem, not a technical one -- the technical matter in this bug is all in comment 0. Let's see those social skills, eh?

What a great idea. I'll start by pledging to mail (or paypal) $20 to the coder (or team) who implements this RFE. Who else is in? With 30+ voters on this bug we should be able to amass a decent kitty.

This is a great idea. I will add $30USD to the pot, paid via Paypal, to the coder who takes ownership of this bug and ends up with the following Image options (some of which exist already I know, but for the sake of completeness): "Blacklist" - allow all images to load, save those that are blocked (functions now) "Whitelist" - block all images save those that are allowed (bug 145690) "Confirmation" - for each image not explicitly blocked or allowed, ask what to do. (this bug)

Sounds like a good plan. I'm in for $20 USD. Someone should propose an equitable system for collecting the money from donors before coding starts, holding it in escrow until someone completes the coding. Those (suddenly) interested in coding should coordinate with each other to avoid duplication of effort and unexpected loss of the kitty. We've got 31 votes and 29 people on the CC list. We should be able to get enough pledges to attract *somone* to do this. Or we'll have Betty White do a telethon...

I would think the reporter would be a good choice for an escrow point. I also think that no netscape employee (or at least, not waterson@netscape.com) should be eligible for the "payout" as well - it sets a terrible conflict of interest up where it is in their best interest to "hold ransom" a bugfix until the community is willing to "pay up", and I'm certain that Netscape would not appreciate that kind of press. :)

Sounds like a good idea to me as well. I am willing to contribute $20 USD for a blacklist/whitelist/confirmation fix as summarized by K. Snider.

Have no worries on waterson... unfortunately he's been pulled off Mozilla development altogether (too bad; he was one of the more competent people...)

Sounds good to me. I also will donate $20 to the coder via Paypal. I only needthe original solution via a confirmation dialog. No UI setting neccessary as long as Mozilla honors the 'user_pref("network.image.warnAboutImages", true)' setting. I do not care if it crashes every once in a while. And whoever took it out was a bozo POINT

Actually I believe it crashed only when you replied differently to the two questions you were asked if a site has a background image. So the proper way of fixing the bug was not to make Mozilla ask you twice about the same thing. The crash was only a pretext to quash this feature.

You believe incorrectly. In fact bug 110112 comment 0 shows that you believe incorrectly. Now if only you would fucking read before spouting...

I read bug 110112 comment 0. Even as I did not do it while fucking (how do you do that, Boris?), I simply do not believe in that comment. I simply stated the very fact: IMHO the only reason you crashed with image confirmation were contraditory answers on tho questions about the same host.

I'll add the reason for my belief: I still use the last 1.0 branch nightly (2002080806) which has the image confirmation (this "fix" made me do that) for my everyday use and I _never_ crashed since I understood the pattern and started to be careful not to contradict myself.

I'm having a different experience with 20020529: Mozilla crashes on me even though I'm always consistent in my image confirmation responses for the same host (I don't see why I wouldn't be). I haven't been tracking whether it also crashes when I'm giving different responses to different hosts while loading a single page, but off the top of my head, I don't recall it making any difference.

I is possible that a fix for a different bug changed something for better between 20020529 and 20020808. But we will never know after the problem was solved using an sledgehammer. The very reason why the code (maybe minus the GUI) should be in the trunk tree is that otherwise all bug testing including the discussion we have now is actually moot.

One more factual comment I have. It is entirely possible that caillon's work to load images from content instead of frames will make this bug partially moot, in that for <img> the check/dialog/whatever will come from _content_model_ construction, not frame construction. If people want a dialog on background images as well, however, then the problem remains for those.

Reassigning Image Manager bugs to mstoltz and clearing milestone.

This bug was accidentally marked security-sensitive yesterday. Removing security-sensitive status now.

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

Hoping to kickstart this, I thought I'd share my notes on this. Unfortunately, I don't have much experience either in C++ or XUL. But, I tried putting in a breakpoint in Permission_Check (which is where, and this is the call stack: Permission_Check IMAGE_CheckFor Permission nsImgManager::ShouldLoad nsContentPolicy::CheckPolicy nsContentPolicy::ShouldLoad NS_CheckContentLoadPolicy nsImageFrame::CanLoadImage nsImageFrame::RealLoadImage nsImageFrame::LoadImage nsImageFrame::Init nsCSSFrameConstructor::InitAndRestoreFrame nsCSSFrameConstructor::ConstructHTMLFrame nsCSSFrameConstructor::ConstructFrameInternal nsCSSFrameConstructor::ConstructFrame nsCSSFrameConstructor::ProcessChildren nsCSSFrameConstructor::ConstructTableCellFrame nsCSSFrameConstructor::TableProcessChild nsCSSFrameConstructor::TableProcessChildren ... Any suggestions on where respective steps in waterson's description of this bug's fix should go?

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

Adding dependancy on bug 83774. It looks like Boris has taken up the work he mentioned in comment 46. With some luck, hopefully Boris' speculation will prove true and give us the opportunity to resolve this bug.

As far as comment 50 goes, the place for steps 1 and 2 from comment 0 would be in nsImageFrame::CanLoadImage after NS_CheckContentLoadPolicy returns and steps 3 and 4 would be off the event you'd post if you need to ask. That said, the image loading code will hopefully be moving over into nsImageLoadingContent soon as mythdraug says.... At that point, we can revisit this bug.

Ok, I thought about it. We can't put up a modal dialog from inside content model construction either. That would break things badly, possibly worse than doing it from frame construction. So comment 0 still applies. Steps 1 and 2 would happen in nsImageLoadingContent::ImageURIChanged or nsImageLoadingContent::CanLoadImage. Steps 3 and 4 would happen when the event you post in step 2 fires.

This page is getting so long I can't even get mozilla to load it. :> That said, two seconds ago I got email stating a dependency bug was fixed. Does this mean there's hope for a re-implementation? I'd love to be able to finally upgrade again.

-> nobody

Changing description. I recommend Wontfix, but I leave that to a future module owner.

Definitely not happening in Core or Firefox, as it would cause dialogs to appear on almost every web site. Could possibly happen in the ImgLikeOpera extension or another extension.