Features disappearing from menus



18 years ago
13 years ago


(Reporter: J. Nick Koston, Assigned: Mike Pinkerton (not reading bugmail))


Firefox Tracking Flags

(Not tracked)




18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (X11; U; Linux 2.3.99-pre4 i686; Nav)
BuildID:    2000041508

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.

Reproducible: Always
Steps to Reproduce:
1. open mozilla
2. right click on an image
3. be very disappointed


18 years ago
Component: XP Toolkit/Widgets: Menus → Browser-General

Comment 1

18 years ago
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

load images.

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.

Comment 2

18 years ago
Feature may be going away, at least temporarily, due to the number of sites it 
completely broke. See bug 33576.

Comment 3

18 years ago
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
something like
http://domainnamehere.com/ads/ .. might be nice to go as far as regexs, but that
isn't very useful to the typical enduser.

Comment 4

18 years ago
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.
Last Resolved: 18 years ago
Resolution: --- → WONTFIX

Comment 5

18 years ago
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

Comment 7

18 years ago
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!!!

Comment 8

18 years ago
mozilla.org should open another bug to change the default behavior for mozilla 
if so desired.

Comment 9

18 years ago
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 
simply isn't.

    And lastly, what's with the hostility towards America Online?  May I please 
remind you that this so-called "totalitarian corporation" is largely funding 
this project?

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 :-)

Resolution: WONTFIX → ---

Last Resolved: 18 years ago18 years ago
Resolution: --- → INVALID

Comment 12

18 years ago
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 

Comment 13

18 years ago
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 
private branches. 

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. 


Ben Goodger
mozilla.org UI lead

Comment 15

18 years ago
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! 

Comment 16

18 years ago
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.

Comment 17

18 years ago
Perhaps this bug should be re-opened with the following parameters:

Target Milestone: Future
Severity: Enhancement
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.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.