Go to any page that has an image Rightclick on the image and select block-image from the context menu Reload the page The image still loads.

Actually, if you go to the Image Manager (Tasks | Privacy and Security | Image manager | View sites that can/cannot display images), any site you have attempted to block images from is listed as "site cannot set cookies". This is with build 2001033121

The mis-wording of cookies instead of images is covered in bug 74089. Patch is available and it is currently awaiting super-review.

I'm also seeing this on Linux build 2001040505. Is the patch mentioned in the previous comment one that fixes this bug or bug 74089?

Sorry, I wasn't clear in my comment. I was referring to bug 74089 and its patch. And it now has been checked in.

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

I'm seeing this on Linux build 2001040908. In fact, it's not limited to context-menu image blocking; I have "Do not load any images" enabled and still get new images downloaded. At least banner-style images (like at mozilla.org and mozillazine.org) no longer crash the browser.

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

This also happens in Linux (which I hinted at in my last comment). Should "OS" be set to "All"?

done

really

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

It can get even worse. As of 2001041214 (Linux sea from mozillazine), I can reliably (i.e. I do reproduce it at will) crash mozilla at phoenix.cyril.com when I have image/cookie warning enabled. If I turn both warnings off it works (and no cookies appear in cookie manager, so it's image blocking). Turn both back on and try to load site, instant SEGV. The name of the function I can see at gdb is something image-related (and after something at 0x6... Looks hyperspace to me. Looks like it's jumped to the void). I can post the entire backtrace here if you want. If someone else reproduces this, it means we have a crasher...

The crashing that you are observing is bug 75661

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

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

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

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

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

The symptoms here were strange in that at some sites this appears to be working but at other sites not. Finally bug 77331 explained the dispcrepency. If the images are coming from stylesheets image blocking will work. Otherwise it will not. The url sited in bug 77331 which demonstrates this is http://www.w3.org/Style/CSS/Test/current/sec533.htm

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

morse: Now you've fixed bug 77331, do you know offhand if this is still happening? Gerv

Bug 77331 has nothing to do with this bug. That bug dealt with a file destruction that was occuring in the case that image block actually worked. What wasn't clear at first is to why it was even working well enough to trigger bug 77331 but now we know. Image blocking works in the case of style-sheet images but not for normal html images. And the fact that it doesn't work for normal html images is what this bug is about.

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

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

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

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

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

This should work, although I haven't fully tested it. Some null checks here and there would probably be smart too.

The 'block image from loading' context menu option has also disappeared, or at least it never appears now in my random sample of images it used to appear for. (There are some images that it never appeared for, see bug #78617) I'm using 2001052308 trunk build.

Correction to my previous comment. The image block option still exists. The problem I was having is that sometimes when you right click on an image you get the context menu for the page-in-general instead of the one for an image. This seems to have something to do with the nature of the image and the HTML that loaded it, and I can't figure out when it works and when it doesn't. In any case, it's a separate bug. Try right clicking in different parts of the mozilla.org banner; I can reliably get the image menu in the left two thirds and the page menu in the right third.

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

Right-clicking on the right-hand side of the mozilla.org banner *should* give the page menu, since that's not an image. The image ends shortly after the "mozilla.org" text, and the rest is a table background. That's not a bug. On the other hand, after a server is on the image blocking list, "block images from this server" no longer appears on the image menu for images from that server. That also doesn't seem like a bug to me, but because of *this* bug (that images don't get blocked) it's just confusing.

Thanks for the clarifications. Sounds like there isn't a second user-interface bug.

Just confirming: Image blocking doesn't work in 0.9.1 latest build id 2001-06-01-16 windows zipped version Reproduce after setting block or don't accept images in pref: Open menu Debug + View Demos + #2 images While your there check out bug http://bugzilla.mozilla.org/show_bug.cgi?id=77914 black background on transparent gifs. This 0.9.1 latest should come much later IMO

We either need to get this patch finished, reviewed and super-reviewed for 0.9.1 or remove the image blocking UI. Which is it to be? Gerv

There will be lots of negative reaction to a release of the browser that makes it impossible to control what content you receive from a site. Those whose phone calls are per-minute charges when they dial up will be particularly hesitant to try it out until they can force it to get only the text content of a page they're visiting. That's what's pushed me back to Netscape 4.77 or Konqueror [only 2.1.1] for the moment, for instance. B

the patch is ready to go i think.

OK, let's try and get the patch in, then. (Pav: hope you don't mind me messing with your bug.) Gerv

we may want to consider going w/ the patch in http://bugzilla.mozilla.org/show_bug.cgi?id=84162 instead.

adding dependancy on 84162. lets check that in instead. moving back to 0.9.2 since there is no way netscape will let this get checked in for 0.9.1... mozilla might however, so if you want to get an a= from mozilla, go for it.

I don't understand how the patch in bug 81462 will magically make image blocking start to work again. I thought the problem was that at image loadtime we weren't making the calls to check if we shouldn't load. Seems like we will still be missing those calls even after the patch in bug 81462 gets in. Has anyone tested that the patch in 81462 actually makes image blocking work again?

Morse: You certainly mean bug 84162, not 81462. I was really surprised that "Missing OS/HW in default distro" can block anything ;-)

Note: this patch has r=valeski from IRC. Gerv

we should snuff this bug out (dupe it?) in favor of 84162.

valeski: That assumes bug 81462 fixes the problem. Morse doesn't seem too sure about that. Can you confirm it does? Gerv

84162 fixes the problem w/ a tweak I'm waiting on pavlov to comment on. it's also more architecturally sound, uses an existing callpath (won't impact performance at all, as this patch will), and uses a more prolific load blocking model. after some thought and further inspection, I'm actually going to have to pull my r= on this one because I don't think it covers all the image loading cases (like DOM element src attribute loads), which 84162 does (by virtue of using nsIContentPolicy). If we want to persue this patch, we'll probably need to add blocking to these sites as well http://lxr.mozilla.org/seamonkey/search?string=nsIContentPolicy%3A%3AIMAGE%2C .

this patch is pointless if you make nsIContentPolicy check cookie/wallet stuff.

Fair enough. But then bug 84162 has to get in by day-end, for the same reasons that this one was so urgent :-) Gerv *** This bug has been marked as a duplicate of 84162 ***

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

Verified Duplicate