From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (X11; U; Linux 2.3.99-pre4 i686; Nav)
It seems that the "block this image from loading" feature has disappeared from
the menu. I don't know if this is an oversight, or if it was intentionally
removed. However I'd like to see if come back.
Steps to Reproduce:
1. open mozilla
2. right click on an image
3. be very disappointed
It appears that the whole selective blockingh of images feature of Mozilla has
gone missing in recent nightly builds (2000041316), perhaps it's just a
temporary disabling of this feature until some bugs have been ironed out.
It used to be possible to selectively allow sites to load images in exactly the
same way as it is for cookies, in fact the block images listrused to be
contained in the cookie manager and in the preferences menu was in the same
location as the cookies menu.
I'm changing the subject as it appears you're after the feature to selectively
As this isn't specifically a Menus issue I'm reassigning to browser-general as
I've got no idea which component this should be assigned to, it appears to share
a lot of code with the cookie manager if that helps.
If someone knows what's going to happen with this feature and who's responsible
for it then we can assign the bug properly or close it if the feature is going
to be reenabled soon.
Feature may be going away, at least temporarily, due to the number of sites it
completely broke. See bug 33576.
Perhaps its just needs to popup a box that says, "This action will block all
images from this domain". Or even better it will let you edit the match
string. Ie. You could get a box that says. This will block all images from the
urls that matches the below string:
by default it would popup http://domainnamehere.com and you could change it to
http://domainnamehere.com/ads/ .. might be nice to go as far as regexs, but that
isn't very useful to the typical enduser.
I noticed this a couple days ago and commented on it; Steve (Morse) of NS wrote
me back letting me know that management had told them to strip the feature. His
words: "It went the way of management decree." Because of this, marking WONTFIX.
Well, its back to the squid filtering idea.... I was hoping the feature could
be improved instead of dropped. However it seems anything that would be done on
it would be futile. :-(
I guess being able to block ads would be a _bad thing_ since NetscapeAOL has
them everywhere. I've lost a little faith in mozilla (I was under the
impression mozilla was not NetscapeAOL, however I guess I'm wrong). However
this was expected, even predicted.
Well its not a total loss, the mozilla project still kicks ass, keep up the good
Let me clarify something here. Contrary to popular opinion, this feature was
never "yanked" from the product! It's still there, alive and well, and getting
compiled into every build. It's all under control of a pref
(imageblocker.enabled). The pref is currently defaulted to "false" (in all.js)
but an implementation is free to change that if it chooses to do so.
Please don't go attributing any other quotes to me -- they just aren't true!!!
mozilla.org should open another bug to change the default behavior for mozilla
if so desired.
This has gotten a little out of control. The only thing Steve Morse informed me
was that as of now, the image blocking prefs have been *publicly* removed from
the build. This means that though you CAN still retrieve the feature if you so
desire, the menu options and interface are not -- by default -- accessible.
This is done often for testing purposes; if something you're working on seems to
be conflicting with the image blocking module, you can simply opt to turn it off
to complete your work. Who the heck said anything about it being removed
permanently? Admittedly, my note wasn't clear, but I think blaming AOL for the
supposed "removal" of this feature is absurd and a little conspiracist, don't
you think? To the news sites carrying this: I'm sorry, but what we have here is
a nonissue. Are you going to report _every_ time a feature seems to be publicly
missing from a build? You're gonna be doing a lot of updating.
To clarify: the ONLY piece of information Steve gave me was that the feature,
as of now, did not appear to be in the latest builds, but really was. His words
that the feature 'went the way of management' decree simply refer to the fact
that 'management' (NOT AOL management or even AOL-related, mind you) told him to
turn the image blocking preference off by default in the latest nightly builds
(probably so some technical issues that the feature's causing can be ironed
out). That's it - I apologize for the ambiguity of my original words, but they
never meant to imply the removal of this feature. Nor did Steve's.
I also appreciate sites like kuro5hin.org who are actually making an effort to
get what really happened across to alarmed readers, unlike some other sites
who expressed no interest in inquiring about the truth (advogato). In any case,
I find it hard to believe that news sites would even bother to carry this story.
Lots of things change before release. Nothing's done yet. A fantastic new
feature might be added today; likewise, the decision could be made tomorrow to
cut the 'Reload' button. Who knows? It's entirely fair to critize a public
product, but to judge it by its shortcomings when it's only in beta stages
And lastly, what's with the hostility towards America Online? May I please
remind you that this so-called "totalitarian corporation" is largely funding
By the way: some of you have posted elsewhere with comments that seem to suggest
I have something to gain from this. I don't. I am NOT a Netscape employee, I'm
in no way affiliated with Netscape. And no, as others have indicated,
Netscape hasn't "threatened" me, no one's asked me to say anything, etc etc.
I'm a volunteer working on Mozilla, and I expressed just as much concern as you
all about what happened to this great feature. I was the one who initially
reported it! So please, let us close up this little issue - I accept blame for
not clearly stating what happened to the feature, but there's no reason for
alarm: the feature is still there and working fine.
Blake - recent Bugzilla convention (as far as I've seen) is to resolve bugs such
as this one, which are not bugs at all, as INVALID rather than WONTFIX. Given
that, in this case, WONTFIX also gives rather the wrong impression (as this
feature is still there, and, I assume, will be back in the prefs when the
current problems are resolved) I am re-resolving this bug as INVALID. Hope
that's OK with you :-)
agreed, the WONTFIX resolution gave many people a false alarm.
verifying INVALID: the original bug reported that features were 'disappearing
off the menus'. Thus, it's invalid because such a disappearance was
This bug has made its way to lots of news sites...
A word of clarification:
mozilla.org always welcomes quality code, and features that benefit users.
mozilla.org will have the features it chooses to have, regardless of what any
commercial entity (Netscape, IBM, Intel, Sun, or whoever) decide to do with
I believe this is nothing but a misunderstanding. From what I've heard, the
image blocking feature still requires some more work. Other features have had
their UI turned off in the past when they were not complete so that the
developer implementing the back end was not flooded with bugs relating to it
until the feature was ready to go live.
mozilla.org UI lead
This has obivously gotten way out of hand. At first it appears to me that
"management" declared that this feature should "go away." It appears that I
wasn't the only one under that impression. Now it appears that the feature has
just been pulled because there were problems with it that were creating to many
support issues (would have been nice if an option to turn off/on in
pref->debug). However, I'm looking forward to seeing the feature reappear
sometime in the future. As usual, keep up the good work!
Morse, would I be right in assuming that the main reason for the image-blocking
feature being hidden is bug 33576? If so, interested readers (those who have a
Bugzilla account, at least) can go vote for that bug, or (even better) make
patches to fix it.
Perhaps this bug should be re-opened with the following parameters:
Target Milestone: Future
Depends on: bug 33576
That seems to more accurately describe the situation of a feature that is
currently disabled due to a bug, and formalizes the link between the two issues.
I've turned this back on for the Mozilla builds.