Closed Bug 94035 (BlockFlash) Opened 23 years ago Closed 11 years ago

Allow blocking of any media type (flash, plug-in, applet, etc.) by site (like cookies and images)

Categories

(Core Graveyard :: Plug-ins, enhancement, P4)

Product:
Core Graveyard
Component:
Plug-ins
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: nnbugzilla, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [PL:P3][Plug-in Mgr][parity-IE]see comment 7 for related bugs. see also bug 78104 (pattern-matching blocking))

Attachments

(5 files, 1 obsolete file)

Problem - unable to get flash pop-up info for entry into add blocker.
162 bytes, text/plain
Details
plugin-blocker.js (v.03)
5.96 KB, text/plain
Details
mock-up example of in-page plug-in handling and allowed-sites plug-in gui
17.47 KB, image/png
Details
mock-up example of in-page plug-in handling and allowed-sites plug-in gui
17.47 KB, image/png
Details
Tons of Error Console file accepted.
239 bytes, text/plain
Details 
Hope this isn't a dupe, but the only other bugs I found seemed to have very
specific, narrows scopes (e.g. Flash only).  I'd like to request the ability to
block any type of media, by site, the way that images can be blocked now.  This
is to address all the annoying Flash ads on various sites, but the scheme should
be general enough to handle any new media types that come along.

Ideally, you can right-click the ad (or something, since Flash animations
currently produce a Flash-specific context menu) and get a context menu with an
entry for "Block <MIME type> from this server".
it probably is a dupe...
Hardware: PC → All
Whiteboard: DUPEME
Bug 85621 is similar, but more specific.  Other than that, I came up empty on a
query.
So, this would be about a generic abillity to block an arbitrary MIME type from an 
arbitrary server?
Greg, I suppose so.  I don't know enough about the internals of Mozilla to know
the best way this would be accomplished.  For example, how would a web page
specify to display a Flash animation or a Quicktime movie?
Warner, those things are determined by MIME type. That's the thing that
distinguishes a web page (MIME type "text/html") from a QuickTime movie
("video/quicktime") or a Shockwave Flash animation
("application/x-shockwave-flash"). It is somewhat analagous to dot-filename
extensions on Windows/MS-DOS or type codes on Mac OS.

If Aillon can't find a dupe on this, there probably isn't one. ^_^. Confirming RFE.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Possibly a dupe of bug 24418?  At least, they seem to have somewhat similar goals.
These four bugs are related:

bug 11875 stopping animations with Esc should also stop applet animations
bug 19118 Plug-In Manager (ui for choosing mimetype-plugin associations)
bug 24418 Allow user to turn on and off rendering of video/audio 
bug 94035 Allow blocking of any media type by site
70805 [REF] implement Macromedia Flash blocker
This is a dup of a bug which I also can't find, but which is assigned to shaver 
or brendan or someone like that and is something to do with content-loading 
policies.
Throw in "all" as a choice for the media-type, and you have the ability to
completely blacklist an annoying site (bug 33469).
*** Bug 107126 has been marked as a duplicate of this bug. ***
Whiteboard: DUPEME → [Aufbau-P4] DUPEME
Whiteboard: [Aufbau-P4] DUPEME → DUPEME
*** Bug 107345 has been marked as a duplicate of this bug. ***
*** Bug 109515 has been marked as a duplicate of this bug. ***
Well, I just ran into my first Flash advertisement.  This seems
like a useful idea to me now.


Myth: for flash ads, what we really need is bug 11875, "stopping animations 
with Esc should also stop applet animations".  (Thanks to the way flash 
promotes gratuitous animation, bug 11875 could be useful for non-advertising 
flash as well.)
I don't think stopping the animation after it is shown in the browser is the
same thing as not allowing the animation to be downloaded at all. We really need
both.
Agreed.  My intent with this bug was to have the equivlent of the current "Block
images from this server", but make it general.  Why should I even look at the
first frame of a Flash ad at all, for example?  And it seems to me that if we
can do this for images, we can do it for almost any mime type.
It doesn't seem like anything like this will be implemented
in Mozilla anytime soon. In the meantime I've entered
this into my "chrome/userContent.css":

  object, embed {
    display: none;
  }

It sure made those annoying flash ads disappear!
(", embed" is probably not needed.)

This approach can probably be improved on with
more precise selectors based on attributes.
I'd say, we need a hash of blacklisted URLs - to make it fast enough. Every
object,flash,gif,... (URL) should get checked against it, before it gets
displayed. And there needs to an easy way to click those flashes away (and into
the hash), I'd call it the "****-click".

If it's possible to drag/click URLs of html-pages into the hash,
it will also work for Ad Pop-ups.

just my 2c
wegmann: that would be a separate bug. This one is for blocking based on MIME
type, not location. So you could, say, block all sounds or all animations.
I see that this is different from other content blocking bugs like bug 78104.
But wouldn't it be sensible to have a meta bug tracking all stuff that is
related to content blocking. What we want in the end is the possibility to block
any content, be it images, plugins or cookies based on as many paramters as
possible (server, site, patterns, size etc.). Right now I have the impression
that this stuff is all over the place and not really coordinated.
Garth, this bug *is* for blocking by both MIME type AND location (that's the "by
site" part of the bug description).  When I filed it, I hadn't thought ahead to
blocking by a lot of other parameters, but figured that it might be easiest in
the short term to extend the current image blocking, but allow any MIME type.  I
was hoping that meant the Mozilla developers could implement this fairly
quickly.  Alas, I guess it's not to be.
Ah, sorry. My bad.
Question: Is it even possible to know the mime type of a url _before_ it has
been downloaded? I have seen plenty of situations where the mime type you get
back has absolutely no relationship to the file extention of the url you
request-- even in one of my own scripts.

For example, check out
http://hamsterrepublic.com/dyn/picture/james/lapis_accusant.png

Even though the url ends in PNG, what you are getting back is a text/html page
which puts the *real* picture in an IMG tag along with a description.

So would mime-based content blocking have to happen *after* the content is
downloaded?


James, I don't know the right answer to your question.  I think in some cases it
should be possible to block by the MIME type.  Or perhaps this should block
based on the HTML tag?   For example, image blocking currently happens by <IMG>,
I assume, and not by the extension (.gif, .png, etc.)  I simply don't know
enough about how Flash anims or Quicktimes are supposed to be put in a page.

Either way, at least there's a bug filed on it.  We just need someone really
smart to figure out a good way to do it :)
Flash & java applets, embedded movies etc. are usually entered to a page using
the <object> tag.

However blocking by tag can be tricky: Images, for example, can be loaded using
either <img>, <input type="picture">, elements' "background" property and I
guess that using <object> and <embed> as well.
Therefore the best way to block a media type would be to check for either the
MIME type - that's what it's there for. I guess the file extension could be used
too.
Wouldn't it be possible to just send the request to the HTTP server, get the
"Content-Type" string and terminate the connection?
That would slow things down, of course, but it's still better than having to
load the whole object.
Isn't that what the http HEAD method is all about?
Blocks: 147866
Why not rename "Image Manager" to "Media Manager" and have it block all media
(both images and plugins) from listed sites?  Or might it be enough to lump just
all plugins together, and block all plugins from a given URL?

And here's a good question related to mimetype blocking.  What currently happens
if Mozilla sees an object tag, goes to load the URL (because it doesn't know the
type yet), and receives a mimetype it doesn't have a plugin for?  I imagine if
you blocked the plugin for that location, it would do the same thing.

If Mozilla first gets the HTTP headers, it doesn't necessarily have to load the URL.
burpmaster: IIRC when Mozilla can't find a plugin to match a MIME type, it
prompts to download a plugin for that MIME type. I don't think that's the
behavior we want here.

And blocking all media from a site is only half of this RFE. I might want to
block audio from all sites, but still load images on all of them. Or I might
want to block audio on a site with a particularly awful background MIDI that I
otherwise was to use normally.
When I suggested the "Media Manager", I had ad blocking in mind.  If you block
images from ads.whatever.com, it's a safe bet you also want to stop flash.

And I guess this wasn't clear, but I also suggested the possibility of having
image blocking and plugin blocking seperate, where the plugin blocking blocks
all plugins, not specific ones, from the URL's you give it.  This would avoid
any network activity to check the mimetype.

Also, I was referring to what was happening on the network level when a plugin
can't be found.  If it always requests the header first, then blocking by
mimetype would have no problems.  If it requests the whole file, then cancels,
it wouldn't be a big deal to add one more case where it cancels.

There is an argument for blocking all network activity.  Imagine someone has
<img src="http://tracker.evil.com/track.cgi?123">.  You block images from
"tracker.evil.com".  They realize people are doing this and put <embed
src="http://tracker.evil.com/track.cgi?123">.  Mozilla now requests the header,
and people are tracked successfully.  If specific mimetype blocking is
implemented, we must make sure you can block all, and that in that case it knows
to never request even the header.

the comment #32 is also along what I had in mind. (as is #19)
I would also like to see IFRAME and SCRIPT tags blocked, just like image tags
basically, treat IMG, OBJECT, EMBED, IFRAME, SCRIPT (or anything else these
ad-producing companies use to annoy us) similar, ie. extend existing policies
'block from this site'
'allow only from same site'


Speaking of script blocking: although I love Mozilla's current pup-up blocker, 
I'd love to see the possibility to do a per site blocking since some sites have 
useful or necessary pop-ups (very few I use regularly, but still). I couldn't 
find a bug which covers this. Is this now covered by this bug or shall I open a 
new one?
Simon, see http://www.mozilla.org/projects/security/components/ConfigPolicy.html
Only the front end is lacking, and that's bug 38966

*goes on to remove his vote for this bug so he won't get spammed by it anymore*
Yeah, looks like embedded plugins check content policy here:
http://lxr.mozilla.org/mozilla/source/layout/html/base/src/nsObjectFrame.cpp#1256

Looks like images are using this too in frames and content. I'm not entirely
sure how it works, but can this somehow be leveraged to provide a UI?
What I would actually like to see here is something very simple.

Let me create a list of base URLs from which Mozilla is not to load ANYTHING.
That includes images, scripts, plugins, HTML... but the per-server basis being
used now is not sufficient. 

For example: Let's say I like reading http://www.my-fave-site.net/ 
I want to block their ads, but they're loaded by a script located on the same
server as all their other content... say something like
http://www.my-fave-site.net/cgi-bin/adbanner.cgi 
Sometimes this cgi script serves an image. Sometimes it serves a flash
animation. But the site also serves flash and images that I DO want to see.
So I wouldn't want to block all Flash on www.my-fave-site.net.
But if I blocked all URLs starting with the adbanner URL above, all ads of all
mimetypes would quickly disappear.

Cookies would have to be handled separately, of course. I still like the
per-server/per-domain basis for cookies. Leave cookies as they are now.
gknap@uoguelph.ca - This is requested in Bug 78104.
Does this bug block on Buf 152245 or are they duplicates?
Blocks: 152245
Blocks: useragent
*** Bug 70805 has been marked as a duplicate of this bug. ***
*** Bug 156283 has been marked as a duplicate of this bug. ***
*** Bug 156970 has been marked as a duplicate of this bug. ***
*** Bug 158341 has been marked as a duplicate of this bug. ***
*** Bug 158259 has been marked as a duplicate of this bug. ***
Alias: BlockFlash
You can use the "zap embeds" bookmarklet to remove flash/java/iframe ads from a 
single page.  http://www.squarefree.com/bookmarklets/zap.html
*** Bug 159401 has been marked as a duplicate of this bug. ***
*** Bug 159437 has been marked as a duplicate of this bug. ***
*** Bug 160341 has been marked as a duplicate of this bug. ***
No longer blocks: 152245
*** Bug 162334 has been marked as a duplicate of this bug. ***
*** Bug 162913 has been marked as a duplicate of this bug. ***
*** Bug 163895 has been marked as a duplicate of this bug. ***
*** Bug 163902 has been marked as a duplicate of this bug. ***
*** Bug 166559 has been marked as a duplicate of this bug. ***
chg summary based on duplicate summaries to make this bug easier to
find
Summary: [RFE] Allow blocking of any media type by site (like cookies and images) → [RFE] Allow blocking of any media type (flash, plug-in, applet, etc.) by site (like cookies and images)
Whiteboard: DUPEME → see comment 7 for related bugs. see also bug 78104 (pattern-matching blocking)
*** Bug 166760 has been marked as a duplicate of this bug. ***
FYI, with IE I block all attempts to download or display Shockwave content via 
the following in blcokshockwave.reg, double-click on the file to add it to the 
registry:

REGEDIT4

[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX 
Compatibility\{166B1BCA-3F9C-11CF-8075-444553540000}]
"Description"="this prevents Macromedia Shockwave from running when flags are 
00000400"
"Compatibility Flags"=dword:00000400

This one turns it back on:

REGEDIT4

[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX 
Compatibility\{166B1BCA-3F9C-11CF-8075-444553540000}]
"Description"="this prevents Macromedia Shockwave from running when flags are 
00000400"
"Compatibility Flags"=dword:00000000

This is the same mechanism used to block virus/trojan or otherwise unsafe 
controls, called setting the kill bit. I leave SHckwabve disabled for all sites 
until I happen across one where I need it. Then I turn it on for that site and 
off again afterwards.

Replace {166B1BCA-3F9C-11CF-8075-444553540000}] with {D27CDB6E-AE6D-11CF-96B8-
444553540000}] to get versions which block Flash instead of Shockwave.

Note that it is becoming more common for sites to display Flash based content 
with the intent of getting the user to allow Flash for the site. Once you turn 
Flash on for the content you get hit by the ads. For now my solution is good 
enough. It'll need to be more clever, based on the specific content source as 
well as the MIME type.

Also note that the URL of the source isn't necessary reliable. A secondary 
address like ads.somesite.com can be used to serve third party ads via 
redirection. ads.somesite.com can redirect to your favorite hated ad server.

I generally prefer white lists to black lists. Flash is generally bad, 
circumventing privacy and userdata persistence settings, so I'd want it blocked 
for every site except specific parts of specific sites.
Blocks: majorbugs
*** Bug 168212 has been marked as a duplicate of this bug. ***
*** Bug 170367 has been marked as a duplicate of this bug. ***
I'm really sick of those stupid ads where some SUV perpetually speeds across my
browser and pegs my cpu. Voting for this.
I had a related idea: Block links by server/URL. I use Block Images to kill some
ads but that actually makes it worse - They're still there but they're invisible.
*** Bug 172034 has been marked as a duplicate of this bug. ***
Summary: [RFE] Allow blocking of any media type (flash, plug-in, applet, etc.) by site (like cookies and images) → Allow blocking of any media type (flash, plug-in, applet, etc.) by site (like cookies and images)
*** Bug 175256 has been marked as a duplicate of this bug. ***
I use a program called JunkBuster - http://www.junkbusters.com - which is an add
blocking proxy and it allows you to use regex to block add sites.  For example,
yahoo mail often tries to load an IFRAME with flash that looks like this:

<iframe
src="http://view.atdmt.com/AVE/iview/yhxxxaws07200041ave/direct;wi.728;hi.90/01?click=http://rd.yahoo.com/M=234154.2323765.3808763.508688/D=mail/P=m2dvvca111871000/S=150500006:N/A=1241228/R=0/*"
frameborder="0" scrolling="no" marginheight="0" marginwidth="0" topmargin="0"
leftmargin="0" width="728" height="90">
<a
href="http://click.atdmt.com/AVE/go/yhxxxaws07200041ave/direct;wi.728;hi.90/01/time=1035154149737177"
target="_blank"><img border="0"
src="http://view.atdmt.com/AVE/view/yhxxxaws07200041ave/direct;wi.728;hi.90/01/time=1035154149737177"
/></a>
</iframe></center>

Now in my sblock.ini file I put the lines..

view.atdmt.com
us.a1.yimg.com/us.yimg.com/a/1-/flash

and this blocks any requests for files from these servers/paths.

The software is GPL'd too !  It would still be nice to have this functionality
built into the browser but just to let people know there are other options.
If you're going to use a filtering proxy, you may as well use Privoxy
(http://www.privoxy.org/). Privoxy is a fork of Junkbuster, and it's HTTP 1.1
compliant (in contrast to Junbuster which isn't: see also bug 38488).
*** Bug 175736 has been marked as a duplicate of this bug. ***
*** Bug 176752 has been marked as a duplicate of this bug. ***
I absolutely can not stand flash advertisments.  I want the ability to block
them....immediately!
Oh, man!  If I'd known that people wanted it _immediately_, I'd have dropped
everything and worked on it right away!

Seriously, though, you could use privoxy while you're waiting, or you could work
on a patch. You know, just to fill the time.
This get my vote. What I want is this:

Right click on an object and select "Block object"

Then get a menu that looks something like this:

  (x) Block images from server
  (x) Block flash from server
  ( ) Block Java from server
  ( ) Block everything from server
  (x) Also block subdomains

  Server: [doubleclick.net___________________]

  [Cancel]   [Ok]

'everything' would also stop the HTML for pop-up ads that circumvent the
No-popup scripting protection already present. It's still annoying if a window
pops up even if there is no image in there.

Block subdomains should block '*.doubleclick.net'. If they change their internal
DNS names every day or randomize it (with a catch-all type of DNS), it wouldn't
work otherwise.

I would like to be able to manually ADD sites to the blocking list, plus I would
like to be able to IMPORT and EXPORT site-lists, so that people can work
together to set up a huge banlist of all the nasty pop-up sites.

This one get my vote too.
I think this is very imporant to find a solution for this. Both. IE and Opera
are lack of this.
Blocking images (adwares) in age of Flash adwares, is almost useless.

I would change "block flash" to "block flash/shockwave"

I agree that import/export of Blocking routines would be great, but it's thing
for other bug (not reported yet?).

What i want to say is that, if i'm right, there is no way to add this menu on
right-click over Flash/Java object. It's area of plugin.
For those encountering Flash-panic, modify (or create) a file called
"userContent.css" in your profile's chrome directory, with the following:

embed[type="application/x-shockwave-flash"] {display: none; ! important}
object [classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"] {display: none; !
important}
object[classid="classid:D27CDB6E-AE6D-11cf-96B8-444553540000"] {display: none; !
important} 

It doesn't discriminate, but if you find Flash more harm than good, this will
work until the uberdialog is created to block items.


Your kind of solution is like :

'if you dont like popups - use wget or lynx. It's very stable, magnific fast and
solve problem'

This is not a solution. We of course can not install plugins, but i want flash,
i want java... i only want to be able to block this multimedia objects from some
hosts. (and export/import those routines)
What about the following for blocking this type of media?

1.) Right click on page
2.) Choose "Media blocking options..."
3.) Get list of sites displaying media on current page with some type of check
box system to block them.
4.) Hit OK or CANCEL when done.

It should be possible, from the name of the web site, to judge which ones are
just there for your annoyance. If not, once the plugin/image is blocked, it
could be possible to click on the area where is used to be and unblock objects
from that site.
>What i want to say is that, if i'm right, there is no way to
>add this menu on right-click over Flash/Java object.

Well how about this. Right-click _anywhere_ on the screen,
and choose 'Block object'. Then you get the pop-up menu, and
the 'Server' widget is a drop-down listbox in where _all_ the
servers are located that are contacted. (See Page Info, and
then media.) It's usually easy to spot which ones to block.

Here's an example of what it could look like. This way you'd
even be able to easily block embeded objects which you can't
click directly.


  (x) Block images from server
  (x) Block Flash/Shockwave from server
  ( ) Block Java from server
  ( ) Block Javascript from server
  ( ) Never contact server
  (x) Also block subdomains

  Server: [www.verisign.com________________|v|]
           |cert.webtrust.org                |
           |ads.netsol.com                   |
           |ad.doubleclick.net               |
           +---------------------------------+
  [Cancel]   [Ok]


I updated menu a bit with the previous suggestions. Also, the
default value in the box should be the thing you right clicked.
I would suggest adding the block object to the page info/media tab as well. 
Next to the save as button could be a block object button.  This could easily
use the same dialog - obviously giving the default server as the one for the
currently selected image.
Why limit blocking to images/flash/javascript/java? Ads could also be videos or
sound or a new kind plugin. Blocking should be done at the plugin level. If
possible even lower (for instance, I don't want to hear the annoying background
midi file on some sites but still be able to see their mov files).

Also, but then there is a problem with the title, blocking should not be done at
the site level but at the directory/file level. More and more often, ads and
normal media files are hosted on the same server but different directories (for
instance, normal images would be in /images while ads would be in /ads). See bug
78104 for detail about this one.
Is anyone working on implementing this blocking ability, or figuring out how to
do it, or are we all just complaining that we need it? I see lots of complaining
comments, but not much in the way of anybody getting down to business on it.
What can all us complainers do to help get this thing going? :)
The work is in progress on so called Plugin Manager, which will supposedly be
powerful enough to enable/disable individual plugins and/or mimetype handling.
Ren: we cannot block JS files. Usually they are called from code, and blocking
will result in JS errors.
I think that it'll be enought if we'll be able to block Java/Flash/Shockwave/IMG
Popup should also be blocked (by sub-URL/regexp). And IFRAME.
Popups are blocked. Mozilla has great manager for this, and at now we're
improting some ideas from Pheonix.
Iframe? I dont see any reason for this. Alone IFRAME is a part of HTML code, and
i dont see why it should be blocked. IFRAME is 'not-friendly' only with
FlashJava/IMG adwares inside.
I think that Owner of this bug wont take care about it, if we'll continue
discussing 'what more'. We should specify the problem and try to help in solving it.

I think that a problem is simple. We should add possibility to block
Flash/Shockwave/Java objects from specified servers. It would be great if Zach,
Mpt or Mike Shaver would say something about a plans for this bug.
The thing about blocking IFRAMES from certain servers is that some sites will
use and IFRAME to encapsulate an ad. Thus, by saying "I want no iframes from
foo.bar.com", you can block the ads from foo.bar.com.

What I've seen is on Yahoo et. al, they will use an iframe, containing an image
+ alternate HTML, so that even if you block the image, you still get the HTML.

But of cource, how anal do you want to get about blocking ads....

Popups are currently blocked by domain only. As there may be several sites on a
same domain, popups should also be blocked by URL prefix (at least).
Why is this bug still assigned to Matthew P. Thomas? To SPAM the poor guy? 

a) he's "gone" and b) isn't a programmer.
Meaby because he is Component default owner?
I cannot find better component, even if this one
(http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser) is 'going
away'.
I believe this will be incorporated with the plug-in manager work being
addressed within the plug-ins team, reassinging
Assignee: mpt → serge
Priority: -- → P4
Whiteboard: see comment 7 for related bugs. see also bug 78104 (pattern-matching blocking) → [PL:P3][Plug-in Mgr]see comment 7 for related bugs. see also bug 78104 (pattern-matching blocking)
Target Milestone: --- → mozilla1.4beta
Alias: BlockFlash → pluginmanager
DOH! :-(
Alias: pluginmanager → BlockFlash
*** Bug 178124 has been marked as a duplicate of this bug. ***
*** Bug 178129 has been marked as a duplicate of this bug. ***
Component: User Interface Design → Plug-ins
If a site is in the blocked list for images, the block should also apply to
embedded objects:

OBJECT
EMBED
APPLET
IFRAME

Here is a JavaScript function that you can put in a bookmark, to demonstrate this!
(Thanks to http://www.squarefree.com/bookmarklets/zap.html)

javascript:(function(){var d=document; function K(N,t) { var b =
d.createElement("div"); b.style.width=N.width; b.style.height=N.height;
b.innerHTML="<del>" + t + "</del>"; N.parentNode.replaceChild(b,N); } function
Z(t) { var T = d.getElementsByTagName(t), i; for (i=T.length-1;i+1;--i)
K(T[i],t); } Z("object"); Z("embed"); Z("applet"); Z("iframe");})();

Hey, i still cannot understand what for You want to block IFRAME?
If so, we should also block |frame|? What is bad in iframe? The same as in main
page - |object|,|embed|,|image|. If we'd block those 3, we dont need blocking
iframe. Let it stay!
Blocking iframes would block any kind of commercial whatever plugin they are
using, present or *futur*. Also, if the ads become simple html text, you'll
never be able to block them with the plugin manager but blocking iframes would
do it.

In same way we should add ability to block any part of HTML code.
IFRAME is only a part of html code from other file (with scrollbars), I event
dont know how should this looks like... hidden area of IFRAME? Or IFRAME should
be removed from DOM? and this would cause changes in page looks.
As for me it's useless.
"Also, if the ads become simple html text, you'll never be able to block them
with the plugin manager but blocking iframes would do it."

If the ads become simple html, then I think we can say we've won, as long as
they don't use the blink tag. ;)

Google uses plain text ads, and they seem to do fine. No pop-ups, no pop-unders,
no flash-laden iframes...plain simple text marked up with html. I like it a lot
better than the seizure-inducing X10 camera ads. 

We shouldn't be blocking ads for the sake of blocking ads. We should be blocking
the annoying, offensive ads. The one's that launch in pop-ups. The ones that
send flash-**** zooming across the screen. The ones that waste our bandwidth
with huge animated gifs. Not the simple text ones. 

*rant off*
One of the reasons that we allow image blocking is to protect against cross-site
correlation via cookies and content (images, typically, but many sites are
becoming craftier) from centralized ad servers.  If this bug is intended to
flesh out support for blocking content other than images, it should likely apply
to all forms of "out-of-line" content, regardless of media type.

(Which the ContentPolicy APIs permit, of course.)
Focus is being lost on the issue, in my opinion.

Stop worrying about ad blocking for this bug.  The ad issues are irrelevant to
the matter at hand: granular blocking of media types, for whatever reasons.

Jesse Ruderman's zaplets are the kind of functionality we want, but with a more
targeted and automated approach.  That is all.  Agreed?





You could have annoying text ads (get your credit card at www.credit.card.com)
without any flashy stuff (big sale on cars at www.cars.junk.com) like ads hidden
in (buy your viagra at www.v.i.a.g.r.a.com) the articles themselves.
I don't call that winning.

But I don't think we'll reach that point anyway. The websites and marketting
companies just have to make the ads indistinguishable from normal contant
(all-flash website, popup necessary for navigation, part of article in gif, ...)

So short of boycotting the annoying websites or having some kind of AI that
could recognize ads from whatever the content we get (dream, dream), we won't
win this battle, we can only make it harder to create ads.

Anyway, allowing to block iframe (and frame, and blinking text, and bold and
everything) is just more power to the user. Wouldn't that be cool to be able to
hide any word that one finds offending? :)
The only limit should be the GUI complexity. 
For those who're using bookmarklets as a stopgap measure, here's the
Flash-busting bookmarklet I wrote based on the example in the O'Reilly
JavaScript book.  It works on pages with frames, which the Zap Embeds
bookmarklet doesn't.  Any frame or iframe it can't inspect gets replaced with
about:blank (this usually applies to iframes from ad-serving sites.)  Doesn't
touch Java applets, though one could make it do so easily enough.

javascript:function kd(d){var i,a=d.embeds;for(n=0;n<a.length;n++){
a[n].style.visibility="hidden";}}function kw(w){var f,j;kd(w.document);
f=w.frames;for(j=0;j<f.length;j++)try{kw(f[j]);}catch(e){
f[j].location.replace("about:blank");}}void(kw(window));

BTW, on the subject of iframes, I have nothing against them per se.  But they
should be subject to the same filter rules images are, since they're similar in
many ways (a reference to a possibly third-party resource that gets included by
the client).
*** Bug 180479 has been marked as a duplicate of this bug. ***
This feature is badly needed. If only for sites like this, that each time they 
upload a new campaign the flash covers the content:
http://www.tapuz.co.il/tapuzforum/sp/forumpage.asp?id=8

Yuck.
If cannot block from Mozilla, then at least let the info be retrieved for entry
into an ad blocker.
Maybe instead of the traditional right click->pop-up menu approach, the
blocking-flash feature could be implemented on a global (per-page) basis?. I
think it makes more sense.

For example, when you open a page with flash content, a new option would show up
under View->...

View      Go       Bookmarks      Tools    Window      Help
| ----------------
|Show/Hide       |
|Full Screen     |
|----------------| ______________________
|Flash         ->| Enable for this page |
|----------------| Disable for this page|
|Stop            | ~~~~~~~~~~~~~~~~~~~~~~
|Reload          |
~~~~~~~~~~~~~~~~~~


That would save the url and the enable/disable status somewhere into the prefs.

I think it's a much better approach. Let me explain: For GIFs/JPG ads, the
current pop-up behavior is ok, since normal graphics (that you want to see) is
mixed with advertising content of the same type (that the user often does NOT
want to see). 

However for flash, my experience is that on some sites flash is annoying, poorly
implemented, or it just slows down my system due to repetitive cpu-consuming
animations of doubious value, so I want to disable ALL flash content for that site, 

On some others, flash use is well done so I want to leave it all enabled. I have
went thru my recent memory of flash sites and I've concluded that there isn't a
single site where I would want SOME flash content and NOT other, in a single page.

My conclusion is that it would probably be better (and easier, too) to implement
flash restriction on a global, html-page-url basis rather than individual
content-urls.

Anyone with me? Someone thinks you often need ONE .swf loaded and not another,
on a single page? or would you rather prefer to restrict on a per-page basis?

I think "other media type" can be left using the pop-up approach, but .swf is so
special (flash applets might/can intercept and use the right-click call) that a
global per-page approach is preferred.

Comments?

Regards
Fernando
Fernando: I agree that an out-of-band solution is needed, for plugins that steal
the right-click functionality.  This includes Flash, Java, and perhaps others. 
It would be great if there was a way to pass right clicks through to the
browser, bypassing the plugin entirely.  Perhaps something like
shift-right-click or another modifier key.

You suggested a blocker that works on a per-site basis, to be placed in the menu
bar.  This is similar in concept to the existing blockers ("managers") in the
Tools menu.  It would be preferred to have your blocker in the Tools menu, where
the other blockers are, for consistency.

It would be great if *all* external references in an HTML page could have
blocker functionality.  This would include applets, plugins, objects, embeds,
IFRAME's, annoying background MIDI's, and so on.  Perhaps a "Plugin Manager" is
what's needed!  It would extend and generalize the Image Manager, to apply to
all external references, not just IMG SRC.
I like Fernando's idea as well.  Currently I use the "zap embeds" bookmarklet
referred to in Comment #45 and Comment #91 to remove Flash from a page on an
all-or-nothing basis.  Doing this automatically would fit my needs perfectly.

[Krellan:]
> Perhaps a "Plugin Manager" is what's needed!

See the related bug 19118 for this.
My 2 cents and personal preference is that blocking flash (or other plugins)
should belong under "View", more than under "tools"

After all, if I want to choose if to VIEW or NOT VIEW something, it should
belong under View...

One of my main annoyances after the move from NS 6.23 / Moz 0.9x to NS 7 / Moz
1.01 is the removal of the forms save/fill options from the easily reacheable
pop-up menu shown after right-clicking anywhere over the web page, which is now
stuck and hidden into Tools->Form Manager.

Maybe it would be possible to please everyone and make a "Plugin Manager", and
put it under Tools, but still show a "Flash content->Enable/Disable for this
url" option under [V]iew?

Also, on a totally unrelated note (and trying not to abuse this as a chat board
;), anyone knows why/who/when decided that to change the browser's language (to
switch to a different language pack) one now has to go to Edit->Preferences
(about 5 clicks), while it was previously accessible with just 2 clicks, under
[V]iew?
*** Bug 183019 has been marked as a duplicate of this bug. ***
Yeah. Let us block flash. I hate flash.
The easy way to block Flash is to delete npswf* in your plugins directory. 

Note that blocking Flash is only a step in an arms race. Many banner ads that
you want to block are static images, rendered in Flash to get around "block
images from this server". Once you block Flash, they'll figure out how to use
Java, dynamic HTML, XUL, SVG, or something yet to be invented to have little
cars annoyingly driving around your screen.

Here's how it will play out:

0a. You block images from ad.doubleclick.net
0b. They use Flash, HTML, ...

1a. You block resources by MIME type and server.
1b. Advertisers to lie in HEAD requests to trick you.

2a. Allow users to block all page-loaded content (images, JS, Flash, ...) from a
particular server, or from a different server than the page.
2b. The logical retaliatory step will be for advertisers to use random server
names, or to have ads appear to come from the same place as your content.

Note that only major web sites will immediately have the resources to do this.
Major web sites like to do business with the government, and will be
disabled-accessible. 

3a. Moz users will want a 'pretend I'm blind when viewing this page' mode,
combined with a 'load this image' command.
3b. Ads get slipped into HTML. So you read them, instead of seeing them.

4a. Page reformatters, pattern recognition
4b. Random formatting

An arms race is not something that you can win if you fight it step by step. The
best thing to do is to skip ahead a few steps, and let the other guy sweat to
catch up. And, when they do, you'd probably prefer that you never started. 

So, tread carefully, or change the rules. Consider confining content to
fixed-size rectangles or fixed play times to reduce the irritation factor.
*** Bug 184179 has been marked as a duplicate of this bug. ***
*** Bug 184699 has been marked as a duplicate of this bug. ***
Comment #109 is not necessarily accurate. If advertisers are desperate enough,
yes, they will be able to get around anything we can cook up. That doesn't mean
they will do so quickly or universally. Server blocking of normal image ads has
been around for quite a while now (via Mozilla, host files, proxies,
shareware...), yet tons of sites still use normal image ads on dedicated
servers. It seems reasonable that a similar proportion of sites now using Flash
would never bother to change to something more block-resistant. And none of this
makes embed-blocking less of a desirable feature in the meantime.
*** Bug 189195 has been marked as a duplicate of this bug. ***
*** Bug 189560 has been marked as a duplicate of this bug. ***
--> peterl
Assignee: serge → peterl
*** Bug 191771 has been marked as a duplicate of this bug. ***
I think a style rule is a good way to go but has a hard time catching those
cases when the mime type is given by the HTTP server or file extension such as
in full-page mode.

I'm thinking if we wrote the 'effective' mime type out to an attribute of the
embed, object, or iframe tag, then we could have some attribute matching style
rule to disable that mime type such as:

object[_content-type="application/x-shockwave-flash"],
 iframe[_content-type="application/x-shockwave-flash"],
  embed[_content-type="application/x-shockwave-flash"]
{
    display:none;
}

For even finer grain control, the rule could be selectivly applied per site/domain.

Since 'display:none' should only stop frames for being created and may work now,
 using XBL might be advantageous to instead replaced the blocked plugin content
with a placeholder telling the user it's been blocked and perhaps even giving
the option to unblock.
yeah, but it'd be nice if you had two properties, one for content type and one
for plugin url.  right now you can only match on the url string that's in the
html, but if there's a relative path then you can't do anything to it.

object[_content-type=~"^application/"],
 iframe[_content-type=~"^application/"],
  embed[_content-type=~"^application/"]
{
    display:none;
}

object[_src=~"^http://localhost/"],
iframe[_src=~"^http://localhost/"],
embed[_src=~"^http://localhost/"]
{
    display:inline;
}

or something like that so that i can allow local objects to render.

i don't suppose we could add {display:-moz-replaced}
That way I could actually decide to get the alternate content if it's available.

<object data="data:text/html,&lt;replaced would prevent you from seeing this
[the object's data].&gt;" style="display:-moz-replaced"><img alt="You should see
this ]the object's alternative content]"></object>
Modifying content is not a good solution. Someone might already use an attribute
name you proposed, some scripts could get confused by an attribute the script
writer did not anticipate to be there, some stylesheets might break, we bloat
the content and slow down, saving and editing would need to be thought about
this hack as well and so on and so forth...
*** Bug 193992 has been marked as a duplicate of this bug. ***
*** Bug 194101 has been marked as a duplicate of this bug. ***
*** Bug 198222 has been marked as a duplicate of this bug. ***
I've written some XBL that replaces Flash with a placeholder.  While the
placeholder is up, the Flash has no effect (sounds, etc).  Clicking the
placeholder allows the Flash to play (from the beginning).  This allows you to
play desired Flash animations without having to zap each undesidered Flash
animation individually.

To use it, add the CSS from http://www.squarefree.com/userstyles/xbl.html to
your user style sheet (the page links to instructions).

If you want to block Flash outright, use the CSS in comment 71 instead.
In addition to the elements mentioned before (seeming to want to integrate with
the same functionality of 191380
http://bugzilla.mozilla.org/show_bug.cgi?id=191380 ) how about adding a
command-key override for one-shot loading?  In other words, you click a link
while holding SHIFT-CTRL or something and it loads with all features (Java,
Flash, etc) but otherwise not...

One other debate is the blacklist/whitelist/both, and I'm finding I want both
but 195924 is heading the other way -- anyone know if this is configurable?  Or
why this could possibly be a good idea?
Here's an alternate suggestion.  Instead of a modified way to click on a link,
how about a modified way to reload/refresh a page that addes ?

Something like the "load images" button that use to be around for those that
didn't load images by default.

This would allow a page to be viewed in "stripped down" mode, then load the
additional content once that was of interest.
That's a great idea Philip!

It sounds simple and elegant.  Is it?   What would be the hurdles to
accomplishing this type of solution?
Isn't that basically what Jesse has done, and described in comment 123?
Yes, very similar to comment 123 - but potentially for more than just flash.

This helps when there are multiple "blocked" things on a page that you want to load.

Particularly for image blocking - you don't always know what you're missing -
images without sizes for example.  There are some comparable cases (like audio)
that don't lend themselves well to "click here to really load".

That said, shipping mozilla with the ability to choose this "click to load"
behavior for various media types would still be great!
Since bug 90256 was recently fixed which now allows full-page plugins to go
through layout and as a side-effect they go through the OBJECT content policy
checks, it may be easier to fix this bug.

I'm thinking it might be possible to make a plugin blocker by implementing
nsICotentPolicy in C++ or even in Javascript and register with "content-policy"
in the catagory manager. Example can be taken from embedding's
nsWebBrowserModule.cpp and nsWebBrowserContentPolicy.cpp which currently do a
simple boolean check of the  allowPlugins attribute on the docshell which makes
the unconditional disabling work in composer and mail/news. 
Optionally loading specific countent would be good. (Similar to MS IE Show picture.)
Show image already exists as bug 47475.
Optionally loading specific content would be nice for any media type (not just
images).
*** Bug 201958 has been marked as a duplicate of this bug. ***
Since we're at a new UI to allow/deny specific kinds of data, maybe implementing
a solution to bug 85601 (User interface to allow connections to blocked ports)
here would be reasonable? "(allow|deny|onclick) content type (x) on port (y)
from host (z)" ? 
See also bug 169330, "Flash click-to-view", which asks for something like
http://www.squarefree.com/userstyles/xbl.html (comment 121 in this bug).
*** Bug 202989 has been marked as a duplicate of this bug. ***
*** Bug 205188 has been marked as a duplicate of this bug. ***
hmmm, what about this: http://ted.mielczarek.org/code/mozilla/
I think trying to focus on particular media types (like images or Flash) or
particular mechanisms for using them (like IMG, OBJECT, EMBED, IFRAME, SCRIPT,
INPUT src=, BODY background=, usemap=, STYLE, APPLET, FRAME, and whatever else
I've forgotten or gets invented someday) gets quite complicated quite quickly.

And please don't forget that while some people are annoyed by the stuff that
gets displayed, other people are equally annoyed by being tracked, which is
generally accomplished with things that are *not* displayed, and which can use
any media type and any of the mechanisms mentioned above.

Implementing blocking per media-type and per mechanism and per site/domain/URI
would be a tall order, and is probably much more fine-grained than most people
would really use.

But something very simple would still be a big help:  Presumably, whenever a URI
is fetched for any reason, that fetch is performed by a dedicated fetch-URI
module.  Simply have that module compare the URI to an access control list, and
refrain from doing the fetch if it's not allowed.

Code for maintaining lists of blocked servers already exists.  As others have
suggested, it would also be nice to be able to do coarser blocking of entire
domains, and finer blocking of URI prefixes.  For URIs that match nothing on the
list, there would need to be a default action (allow/deny/ask).

Once that is in place, it could be extended, incrementally.  For example, maybe
the fetch-URI call could be tagged with a boolean flag indicating whether the
request was generated directly by a user action (like clicking on a link or
entering a URI in the Locaton field or selecting "load image" from a pulldown
menu) or indirectly as a side effect of rendering a page.  Direct user-initiated
requests could bypass the access control (or could use a different access
control list).  Or maybe some of the per-mechanism and/or per-media-type ideas
could be added.  But let's not be too ambitious right from the start, or we
might never get anything.
My previous comment included a lot of rationale, so let me extract the proposal
itself.

First, enhance the fetch-URI module to consult an access control list similar
(or identical) to the ones already used for images and popups.  (I wonder why
those two are not themselves identical.)  This would not require changing the
fetch-URI API.  For request URIs that match nothing in the ACL, there needs to
be a default action (allow, deny, or ask).

Second, enhance the ACL to list not only servers, but also whole domains, and
URI prefixes.  This would not require changing the fetch-URI API.

Third and fourth (in either order):

Extend the fetch-URI API to take a boolean flag that means "bypass ACL, just do
it".  This flag could/should be set when it is known that the request was
generated directly by an explicit user action (like clicking on a link,
selecting a menu item, or pressing enter in the Location widget).

Extend the fetch-URI API to take a parent-URI; that is, the URI of the thing
that generated the request (or "unknown").  For example, the parent-URI might be
the URI of an HTML page or frame, or the URI of a script or stylesheet, or the
URI of an embedded object.  Instead of having a single default action, there
would be two default actions (each one being either allow, deny, or ask), one
default in case the request-URI and parent-URI share a common server, and
another default if they don't.  This would provide functionality similar to the
"from the originating web site only" policy for image loading.  This leaves the
door open for a more sophisticated comparison function than "same server?", but
I don't know what else you might want there.

These four steps could be done one at a time; each one would be immediately
useful.  Per-media-type or per-mechanism policy control could be added later, if
it's really wanted.
Adam, you just described nsIContentPolicy. So the backend is there. Look at
nsImgManager to see how this can work.
Michiel, thanks for the reference.  It looks like nsIContentPolicy is the hook
corresponding to step 1 of my proposal (but not steps 2-4), and nsImgManager is
a particular policy mechanism that applies only to images.  Apparently, step 1
could be achieved by generalizing nsImgManager into nsContentManager (which
would pay no attention to whether the content is an image or something else),
and doing something similar for the object(s) that maintain the ACL.
I forgot to mention that most of the ACL functionality is already in
nsIPermissionManager.

So what you should do:
- Create a new componenent that registers as a nsContentPolicy, just like
nsImgManager does
- In the ShouldLoad funtion you msut create, ignore the content type, and always
check with nsIPermissionManager. (which you also can copy from nsImgManager)
- Add a type to nsIPermissionManager.idl, ALL_CONTENT_TYPE or something
- Optionally, create a UI. Without it, you have to hand-edit cookperm.txt

Most of these steps can be done as a extension too. You can skip the creation of
the type constant, but that won't be fool proof. Some other extension, or
mozilla itself, might use the same constant in the future.
Doug and Ian have written a new book on creating XPCOM Components:
http://www.mozilla.org/projects/xpcom/book/cxc/

Their WebLock example implements nsIContentPolicy to provide basic URL blocking.
I suppose the example could be extended as a possible solution to this bug.
Target Milestone: mozilla1.4beta → Future
Here you have my vote. I think the 'block images from this server' should at least
also imply to block by default any content that shows animations, since that is 
what a user typically intends when blocking ads.
So that option should be generalized to 'block multimedia from this server'.
Of course, a more general solution would make us all happy !

*** Bug 210255 has been marked as a duplicate of this bug. ***
this bug has my (and a few of the guys here) vote as most annoying thing that
needs to get its self fixed real quick.

even something short term would be cool (like the chrome style solution
mentioned above by Bertilo Wennergren) but that is dependent on url of resource
being embeded.

it is especially important to me as i only have a dialup connection at home and
downloading wads of flash ads does not do much for my resolve
*** Bug 212368 has been marked as a duplicate of this bug. ***
Blocks: 98995
Paul, "Real Quick" is not something that happens in this outfit, unless it's a
critical bug....this now has the status of "P4 enhancement".  This thing has
been meditated on since August of 2001, and so I suggest we not hold our breath.

It's quicker to get a driver's license in Greece that get a P4 Enhancement
implemeted.
However, it's probably worth asking why the active bug with the third-highest
vote count has such a low priority.  After a (brief) search of Mozilla.org, I
wasn't able to find any clear statement of how vote count figures in to the
development process.  Perhaps there should be one?  Obviously, nothing is going
to obligate an independent (or third-party corporate) developer to work on a bug
based on vote count, but especially with Mozilla becoming a nonprofit org, it
seems like there should be some degree of reflection from votes to priority ranking.

On a more practical note, this bug seems a good candidate because it is fairly
concrete; and from what I've read of the discussion, most of the pieces needed
to address it already exist.
Sorry for the spam: I agree that the whole voting system is very confusing at
the beginning when you start getting involved with Moz. Many people believe that
they can influence Moz's development by voting, while in reality votes have zero
influence. I am subscribed to some of the most voted bugs, several of them have
remained unchanged for years, the number of votes mean nothing to no one. In its
current form the whole voting system is useless and creates a lot of irritation
while helping no one. I think this is really something that should be discussed
publicly (in the newsgroups or on mozillazine.org). I'm stopping now, because
this bug is not the right place to discuss this matter, but it definitely has to
be discussed.
How about taking the discussion to MozillaZine forums? There's a thread under
"Firebird Features" in which a "Flash blocker" is discussed
(http://forums.mozillazine.org/viewtopic.php?t=15720). 

Although concerning Firebird, the forum/thread is perhaps a more appropriate
place to discuss these issues.
Here's a concise summary:
votes don't count.
mozilla.org is not a corporation nor is it a democracry (there's actually text
on mozilla.org that talks about democracy) and you aren't paying most of the
developers who volunteer their time and effort to contribute to this project.
now it might be the case that there are ways for you to hire someone to do work
for this project, in which case you are welcome to seek out such avenues, but
you will not find them in this bug.

Please read:  http://bugzilla.mozilla.org/page.cgi?id=etiquette.html especially
the part about no obligation.

If you think that this bug is important (perhaps because it has so many votes)
then you are welcome to and encoraged to create a solution. once you've written
the code to solve the bug you can attach it to the bug and seek reviews. at that
point your comments in the bug are valid and worthy of note. until then please
consider that you might not have anything useful to say. for example, i
shouldn't have to write this comment, it's a waste of everyone's time. but
people asked.
*** Bug 214246 has been marked as a duplicate of this bug. ***
*** Bug 215542 has been marked as a duplicate of this bug. ***
Bug 193972 ("Unable to right click on a plug-in object (e.g. flash) to "Block
Image") seems to be a special case of this bug
Please consider raising the priority of this bug:
Motivation: macromedia flash
* Websites have through flash potential access to a camera and/or microphone
available on your computer,
* Websites can store information (default <= 100 kilobytes) through flash on
your computer. Thus websites can avoid security restrictions on cookies by
simply using flash...

Please take a look at:
http://www.macromedia.com/support/flashplayer/help/settings/
--citation:-------------------------
What are privacy settings?   Applications that are created using Macromedia
Flash may want to have access to the camera and/or microphone available on your
computer.

What are storage settings?   Applications that are created using Macromedia
Flash may want to store some information on your computer, but the amount they
can store is limited to 100 kilobytes unless you agree to allocate additional space.
------------------------------------
re: comment 157
As until now, Camera and microphone are default OFF, but any website can store
per default up to 100 kb, instead of using cookies, which may be blocked.
I was seeing flash ads only as annoying, until I read comment #32.

If you want to read the fine print, at macromedia, they are declaring well what
they are doing, or third parties.
I used http://www.tomshardware.com/ to get a flash ad, and with right click,
settings, I saw I still had that 100 kb allowed.
Erweitert (advanced) gave me more info in german:
http://www.macromedia.com/de/support/flashplayer/help/settings/

Severity of this bug:

Enhancement, as long as blocking Flash or other plugIns is seen as enhancing the
capabilities of the browser.

Major, or critical, if seen, that allowing Flash to store info is circumventing
the cookie blocking settings.

Privacy? We´ve heard of it...
Like I said in comment #144, this can easily be done by implementing
nsIContentPolicy. 

This version of the plugin blocker I made is just a Javascript component
(template taken from nsSampe.js) that will prompt with a confirm box before
loading plugins on the page. It's been somewhat made smarter to remember the
last URL so not to keep nagging for multiple plugins or reloading the page but
I think the next step would be to start using nsIPermissionManager (like
cookies plus made it into 1.4) to make choices for URLs persist across browsing
sessions.
a link that may be useful to those losing patience:
http://texturizer.net/firebird/adblock.html
Another link that may be useful, for those using Mozilla Firebird:
http://extensionroom.mozdev.org/more-info.php/flashclick

This implements an EXCELLENT feature that would be wonderful to have for ALL
embedded media types:
Click-to-view!

That way, the user would still be able to enjoy Flash on sites that use it for a
purpose (such as the infamous Viking Kittens), without having to worry about
maintaining complex whitelists and blacklists.  Desirable sites would still have
full functionality, and sites that use plugins just to annoy (such as Yahoo
advertisements that use Flash) would simply be ignored by the user: the user
simply would not click.  This would even improve speed, because heavy plugins
like Flash and Java would not need to load unless explicitly desired by the user.

It would be wonderful to have this functionality as a built-in part of the
browser, instead of having to be special-cased just for Flash.

re comment #160, #161 I think all these addons do not prevent the flash object
from being retrieved they just prevent the display (using CSS). True blocking
does not even contact the server where the object is stored (this is important
not only to avoid the data transfer but also to prevent tracking and collection
of statistics by passing arguments to the object URL)
Keep your eye on The ContentBlocker on mozdev.org with a capital B for blocking,
not just hiding, and a capital C for Content, not just Flash, but ALL content. 

Even stupid documents/sites can be blocked, only admuncher (right name?) is
better they say, because it can 'mask' your IP#. Hm, maybe I can do that to...

Aloha my friends...
*** Bug 220955 has been marked as a duplicate of this bug. ***
*** Bug 222121 has been marked as a duplicate of this bug. ***
I'm not sure if this has been mentioned before or not, but I think this should
also include the ability to block specific objects, and not be like the current
system for images where you block all images from a certain server.

For example, if you want to block www.foo.com/images/annoyinganimatedimage.gif,
but be able to view all other images on the site. Also the ability to just not
let the specific image animate while allowing other images on the page to do so
would be nice.
Will this feature ever be implemented?  There are a lot of talking on this bug
but it is still NEW, after 2+ years.
Those waiting for these features may wish to try the AdBlock extension. 
see: <http://adblock.mozdev.org/>
*** Bug 225568 has been marked as a duplicate of this bug. ***
*** Bug 225957 has been marked as a duplicate of this bug. ***
*** Bug 227413 has been marked as a duplicate of this bug. ***
I started using AdBlock from mozdev.org a few months ago and it is the best
thing since sliced bread to get rid of the advertisments and other unwanted
stuff.  I have about 15 carefully crafted entries in my blacklist and haven't
seen a single advertisment (flash or otherwise) at all in several months. 
Unfortunately, it still doesn't solve the problem of shutting off the plugins
entirely where they are unwanted.  I can think of at least one site right off
the top of my head (helihobby.com) that crashes mozilla in linux immeadiately
after the page loads because of their **** flash based navigation bar.  Of
course adding helihobby.com to the adblock blacklist will get rid of all the
images on their site, so that doesn't work either...  I would MUCH rather see
the ablity to shut off all plugins for everything and either click on a button
in the page where the plugin should display to turn it on, or set up some kind
of whitelist of sites that should be allowed to run plugins.
I have to agree with the previous poster.

Two years and this bug still hasn't been addressed yet.
Flags: blocking1.6+
Only drivers are to set blocking+ flags, but I'll save everyone the back and
forth and skip the blocking1.6? stage as well; there's no way, IMO, drivers
would hold 1.6 for this.  If someone hurries up with a patch, it could get into
1.7a, though.
Flags: blocking1.6+
Attached patch patch v1 (obsolete) — — Splinter Review 
This makes nsImgManager also block <object> tags, and talks to
nsIPermissionManger for per-host permissions. (nsImgManager file should be
renamed, and move to a sane location....)
Attachment #136933 - Flags: review?(dwitte)
It would seem that the "block images from ..." could be modified to be "block
ads from ..." which would block all images, flash, etc from that server.  A
solution like that would solve most of what the duplicates of this are asking.
That would be a complete misnomer. It would block a lot more than ads, and there
are other reasons to block images/flash/sound/etc. besides blocking ads.
*** Bug 229840 has been marked as a duplicate of this bug. ***
*** Bug 230472 has been marked as a duplicate of this bug. ***
*** Bug 230682 has been marked as a duplicate of this bug. ***
*** Bug 232962 has been marked as a duplicate of this bug. ***
*** Bug 232961 has been marked as a duplicate of this bug. ***
*** Bug 233010 has been marked as a duplicate of this bug. ***
*** Bug 193972 has been marked as a duplicate of this bug. ***
So, almost 3 years later, is anyone even considering this feature ? i.e. being
able to block specific media types on a site-by-site basis. For instance,
perhaps I want to be able to view the ads on one site but not the other. AdBlock
is either all or none...
So, almost 3 years later, is anyone even considering this feature ? i.e. being
able to block specific media types on a site-by-site basis. For instance,
perhaps I want to be able to view the ads on one site but not the other. AdBlock
is either all or none...
Oleg, did you read the bug? Did you see the javascript component? Did you see
the patch, wating for review?
*** Bug 233679 has been marked as a duplicate of this bug. ***
*** Bug 234152 has been marked as a duplicate of this bug. ***
Ignore this comment. A patch has been applied to Bugzilla which might affect the
mail problems this bug has been having - just testing it.  Discussion of the
mail problem can be followed on bug 234159.
God this bug generates a lot of spam!
*** Bug 235433 has been marked as a duplicate of this bug. ***
I just noticed my first *talking* flash advertisement. (one about some memory
booster at ucomics.com)

I'm glad to see this issue is still getting attention and I'll be trying out <a
href="http://adblock.mozdev.org/">Adblock</a>.
For FireFox there is an extension called "Flash Click to View"
(http://ted.mielczarek.org/code/mozilla/). I haven't tried it on mozilla yet (or
any platform other than windows), but it seems to be exactly what I want. Maybe
does not fix this bug, but makes a few hundred users happy :-)
Personally, I would vote to close this bug as the Adblock extension at
http://adblock.mozdev.org adds in this requested feature in an elegant and
optional way.
Please do not spam this bug with ads for firefox or mozilla extensions - the
scope of  this bug is more general and after 196 comments quite well defined.
Please limit yourself to solutions and patches of technical issues. Thank you. 
(In reply to comment #197)
> Please do not spam this bug with ads for firefox or mozilla extensions - the
> scope of  this bug is more general and after 196 comments quite well defined.
> Please limit yourself to solutions and patches of technical issues. Thank you. 

As the reporter on this bug, I must say that I agree with Markus and Kelley.  I
just tried the AdBlock extension, and it does seem to do pretty much what I
suggested.

I DO think that this functionality may be better off in the browser itself, in
this case, since it's just a generalization of code already in place for images.
 But given that, for whatever reason, the Mozilla.org people don't seem in a
hurry to review the current patch, AdBlock is at least a good workaround.
(In reply to comment #198)
As one of the many people interested in this subject, I'd like to say "me, too"
to the comments about Adblock. It does do what I want, and it really is quite
elegant. I am in fact suggesting to all my co-workers to install Adblock without
giving a second thought.

I agree with Warner Young that the Adblock code *should* go into the browser
itself, or else the image-blocking code might be removed altogether, since the
latter is a subset of the former, and Flash is *much* more annoying than any
image (anyone else **** off by the Flash intros? It's such a bad idea that
most of them have a "skip intro" link. What's the point of doing an intro at
all, then?)

In keeping with the movement to reduce Mozilla's footprint, the second idea is
possibly better.

I'd suggest making Adblock an optional but suggested feature that one may choose
to install (or not) directly from your friendly setup GUI.
I don't believe that adblock allows blocking of java or javascript on a per-site
basis, which is something that is possible with Konqueror, Opera and even
Internet Explorer.  I've found you can control javascript on a per-site basis by
editing the user.js file manually, but that's a huge pain and requires
restarting the browser.
add more comments! lets see how many years before this gets fixed. Come on, I
know you want to. As for me, I was thinking of looking into fixing this, now I'm
getting off the cc list and will never look into this again.
Same for me. I am pulling my hands off this. If you want to discuss adblock, do
it in some forum, a newsgroup, or whatever, but not a bugzilla bug.
*** Bug 237232 has been marked as a duplicate of this bug. ***
*** Bug 237379 has been marked as a duplicate of this bug. ***
*** Bug 234098 has been marked as a duplicate of this bug. ***
*** Bug 240838 has been marked as a duplicate of this bug. ***
Comment on attachment 136933 [details] [diff] [review]
patch v1

On second thought, i don't like this patch. let's not add more non-cookie stuff
into extensions/cookie
Attachment #136933 - Attachment is obsolete: true
Attachment #136933 - Flags: review?(dwitte)
*** Bug 243016 has been marked as a duplicate of this bug. ***
I agree, i'd like to be able to block flash ads too.
*** Bug 244456 has been marked as a duplicate of this bug. ***
*** Bug 245452 has been marked as a duplicate of this bug. ***
*** Bug 246730 has been marked as a duplicate of this bug. ***
This bug needs to be fixed. Plug-ins (flash especially) are some of the most
annoying things on the web and also some of the most useful.

I would like to be able to have all plug-ins objects on a page disabled by
default and then enable them by clicking on them when needed. It wuold also be
nice to allow plug-ins from particular sites as is available with pop-ups.

The attached image is a mock-up example of what I mean.

I would be more than happy to help test tihs functionality if (when?) it is
implemented!
This bug needs to be fixed. Plug-ins (flash especially) are some of the most
annoying things on the web and also some of the most useful.

I would like to be able to have all plug-ins objects on a page disabled by
default and then enable them by clicking on them when needed. It wuold also be
nice to allow plug-ins from particular sites as is available with pop-ups.

The attached image is a mock-up example of what I mean.

I would be more than happy to help test tihs functionality if (when?) it is
implemented!
oops, sorry dupe.
(In reply to comment #214)
> Created an attachment (id=151255)
> mock-up example of in-page plug-in handling and allowed-sites plug-in gui
I wonder if this sort of thing couldn't be done as an extension on mozdev at
first, and possibly incorporated once it was slick enough.
Michiel, is there something we can do with this in the framework of bug 219752?
Such as adding entries for embed in hostperm.1 in the same fashion as:

host	popup	1	www.cnn.com
host	image	2	global.msads.net

Could we have a 
host    embed   2        edgesuite.net
Look at comment 143. It describes what is needed. The last two steps are just a
bit easier now. But due to all the spam, the comment has become almost unfindable.
*** Bug 260738 has been marked as a duplicate of this bug. ***
*** Bug 264220 has been marked as a duplicate of this bug. ***
*** Bug 270977 has been marked as a duplicate of this bug. ***
*** Bug 153427 has been marked as a duplicate of this bug. ***
*** Bug 148534 has been marked as a duplicate of this bug. ***
*** Bug 146437 has been marked as a duplicate of this bug. ***
*** Bug 147829 has been marked as a duplicate of this bug. ***
*** Bug 144961 has been marked as a duplicate of this bug. ***
*** Bug 129460 has been marked as a duplicate of this bug. ***
*** Bug 107207 has been marked as a duplicate of this bug. ***
*** Bug 103791 has been marked as a duplicate of this bug. ***
*** Bug 74256 has been marked as a duplicate of this bug. ***
*** Bug 74754 has been marked as a duplicate of this bug. ***
*** Bug 276322 has been marked as a duplicate of this bug. ***
*** Bug 276348 has been marked as a duplicate of this bug. ***
*** Bug 276765 has been marked as a duplicate of this bug. ***
*** Bug 274418 has been marked as a duplicate of this bug. ***
Flash ads are getting really common, but are the source of income for many web
sites.  The ads will include code like:
src="http://a.tribalfusion.com/i.ad?site=OSNews&adSpace=ROS&size=468x60&requestID=1661111426
to identify where the ad was seen.

So that the web sites keep their income, but we don't have to look at the stupid
weiner dog with mortgage rates, provide an option to make the site think it's
serving the ad (I might not want to waste bandwidth on a slow connection), an
option to display the initial frame of the flash ad, and an option for me to
look at the rest of the ad if I really want to look at it.  That way you have
something for everyone.  Even the advertisers will be happy if they realize that
they don't alienate potential customers by forcing them to look at the ads. 
(However, revenues might go down at some web sites.)
Comment 236 does not seem practical, or even desireable, for several reasons.

First, a Flash file is just opaque content to the browser; trying to limit it to
just the first frame would require a custom Flash plug-in, which would be in
Macromedia's hands.

Second, even if it was animated GIFs or some other non-plugin media type that we
render natively, there's no way to fool the server into thinking its sent the
ad, without actually having it send the ad, which expends the user's bandwidth.

Third, many advertisers embed information in the URL of the ad in order to
identify and track the user.  Many users object to being tracked in this
fashion, and use the blocker specifically to prevent it.  

Yes, blocking ads creates problems for advertisers.  However, I don't think
Mozilla/Firefox is targeted at that audience.  :-)
Okay, some of what I proposed isn't possible (having an OPTION to display only
the first frame), but providing options for what may be offensive to different
people IS possible.  Separate:
1. tracking the user (as opposed to tracking the viewing an ad on a particular site)
2. reducing wasted bandwidth
3. reducing offensive/distracting pictures/audio on an individual's machine
Steve Kelem, I'm the originator of this bug, and *I* don't care anymore.  Just
use something like AdBlock (http://adblock.mozdev.org/).  It pretty much does
everything this bug requires.
So, why don't change bug state to WONTFIX?
(In reply to comment #239)
> Steve Kelem, I'm the originator of this bug, and *I* don't care anymore.  Just
> use something like AdBlock (http://adblock.mozdev.org/).  It pretty much does
> everything this bug requires.

As the AdBlock plugin has prooved to be so extremely useful, which not only
seems to be my opinion, why don't we include the functionality into the standard
release (subject to the AdBlock developers agreement to that).
The latest adblock version I have found just hides flash ads, don't stop them
before they load, thus wasting bandwith. I want content being blockable at the
server. To make it worse, flash ad that have sound still play themselves, giving
the maxium of annoyances.

And they even can pop up new ad windows, skipping the pop up blockers (it's
happening to me more and more frequently lately). Is there a way to implement en
enabled by default flash pop up blocker indepedentent from the flash media blocker?

On top of that flash ads are becoming so pervasive (are replacing image ads)
that this should be a core feature.


Steve Kelem: I don't fully understand the features that you request on your
messages, could you elaborate?

In my opinion the only thing we need is 'before it loads blocking'. I don't see
the need to include features that would benefit advertisers (and image ad
blocking isn't used by the majority of Firefox users anyway).

(Extrapolate flash to other kinds of media as needed.)
If adblock doesn't fit this bug, have you all considered the flash disabling
technique used in prefbar?  (http://prefbar.mozdev.org/)
I have to chime in. I recently started using Adblock and I love it too.

A great first step would be to add such functionality to Firefox. Shouldn't
require much development work if the Adblock developers are okay with it.

This would be such a blessing for the average user and further increase the
Fox's popularity.

Ideally the ad downloading/bathwidth would be addressed now but given the choice
of a sooner vs. later (years later?) release, I would be for quicker release
with the ad downloading followed by an update without downloading.


I'm no expert regarding Mozilla and Firefox implementation, but I think
sometimes extensions can't be easily (or shouldn't be) ported into the Mozilla
code. Sometimes extensions are more or less like hacks.
My point was that blocking the ads should be an option, as much as I hate the
ads, there might be one that I (yeah, it's a stretch) want to look at. The
approach in Thunderbird of having a button to Show Images when images are
normally blocked is a good approach for an easy way for the user to override the
default.
No longer blocks: 254091
*** Bug 254091 has been marked as a duplicate of this bug. ***
*** Bug 270460 has been marked as a duplicate of this bug. ***
Blocks: 229196
*** Bug 286658 has been marked as a duplicate of this bug. ***
*** Bug 292509 has been marked as a duplicate of this bug. ***
No longer blocks: majorbugs
1. lots of sites have half their content in flash.
   Some of them also have flash ads on a subdomain or
   third party server, which I want to block.

2. on the others, I want to block all flash.

3. I use Proxomitron to blacklist flash on sites I visit regularly 
   and on all 3rd party sites not whitelisted.

4. I don't want to open proxomitron to blacklist/whitelist a site 
   I may never visit again if I stay 1 minute,
   but I also do NOT want 30 pages full of flash for the next hour browsing 
   yet-another-probably-the-last-page-I-will-ever-see-here!
	I would rather right-click as #32 suggested.

5. Ditto for the one-time visit to the site 
	with the midi that I already heard 50 times

I would also like a setup list with for each mime type a choice to
	block new domains unless I right click (whitelist vs blacklist toggle)

We should block all obvious extensions for a type from being fetched from the
banned server, and abort asap otherwise.

Right-click menu should please have a URL 'submenu' 
	to show the URL in question, and
have an option to ban a server totally
	(or un-ban if right-clicking a "blocked item" icon)

Is this RFE waiting for a patch, or waiting for the 
	excellent gatekeepers to endorse one of these fine ideas?

Does anyone understand how to block flash from storing info on my computer
(ref #157)? (Yes I read macromedia's incomprehensible babble)
Can Firefox prevent this? 
I vote for critical+blocker on this bug.

(In reply to comment #251)
> Does anyone understand how to block flash from storing info on my computer
> (ref #157)? (Yes I read macromedia's incomprehensible babble)

http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager03.html

> I vote for critical+blocker on this bug.

Read the severity descritptions at
https://bugzilla.mozilla.org/page.cgi?id=fields.html#bug_severity. This is not a
Blocker or Criticial. It's an Enhancement.

If we could right click a flash ad and block it I would be so happy.
you'd think after FOUR YEARS you people would wake up and realise that
1. this is not a priority for the dev team
2. there is a very good alternative (adblock extension)
(In reply to comment #254)
> 2. there is a very good alternative (adblock extension)

Read comment #242 for why this is inadequate.

Then realise the mass amount of duplicates we have, most recently noticed in
comments #247 to #250 (inclusive).

The fact that we're still talking about this issue 4 YEARS after this has first
been logged should tell the dev team something about its importance.
#255 - Since I don't work on the Mozilla team then I don't want to speak in any   
kind of an official capacity, but I know that when I get a bug and then someone   
comes up with a 90+% workaround then I'm not going to be in a real big hurry to   
fix things either.  Personally, I'd love to see this thing resolved "WONTFIX"   
since the existing workarounds seem acceptable for a large number of people.    
But there still needs to be a placeholder for dupes.  Of course I could just   
remove myself from the cc: list when I get tired of the thread, but I'm really 
kind of interested to see how the owner of this bug finally resolves it.  
      
      
> ...I'm really kind of interested to see how the owner of this bug finally 
> resolves it.  

The owner of this bug is peterl, and AFAIK he doesn't work on Mozilla anymore. 
       Reassigning bug to default owner for this component (and crossing fingers
it actually goes to someone active).
Assignee: peterl-bugs → nobody
QA Contact: zach → plugins
We can't expect a general user to add an extension. Even for such a useful
extension.

If at least the Adblock features were added to Firefox, it would propel Firefox
from fringe to greatness. (At least until the next invention in the ads arms race.)

I'm just imagining the review in Time Magazine. :-)
One thing I'd like to add to this long thread (wow the comment form is far away
at the head!) is that compared with 4 years ago when this bug was submitted more
Flash ads are appearing now and generally Flash has got more popular.
without right-click flash blocker, image blocker is becomming more and more
useless for filtering ads... in case this issue gets dopped from mainline
firefox, image blocking can also become adblock-only functionality, since it is
practically useless on its own.


(i might as well add some irrelevant comments here, since this bug is already
wontfix-due-to-spam)
Did nobody notice that the bug this one depends on, bug 240070 got fixed? Now it
is possible to block flash based on the hostname. The only problem is that there
is no UI for it.
(and don't even think about spamming bug 240070 or some other bug if you ever
want to see more work on this front)
(In reply to comment #254)
> you'd think after FOUR YEARS you people would wake up and realise that
> 1. this is not a priority for the dev team
> 2. there is a very good alternative (adblock extension)

I don't want to be annoying about this, as I already mentioned it in #242, but
AdBlock does not avoid flash ads playing themselves, it just hides them
visually, so if the have sound, you still hear it. And as #259 said, this is
getting worse day by day.
If it's just Flash that's the problem, why not just use Flashblock?

http://flashblock.mozdev.org/
(In reply to comment #261)
> Now it is possible to block flash based on the hostname.
> The only problem is that there is no UI for it.

Actually, it seems nsContentBlocker uses one of 8 possible values (image,
script, etc. but not flash or other types), while nsPermissionManager takes a
content type string (which I can't tell whether or not are supposed to
correspond somehow to MIME content types). So it's not as simple as writing UI,
it would seem you need to at least change the content blocker...

But wait, there's more! When you look into nsPermissionManager you find that
those strings you pass it end up in another array, whose number of entries is
limited to 8. Isn't that swell?

So you have to think about:
- When and where are types determined for entities you're about to get from a
server?
- How to expand that mechanism to also find it is about to get 'flash' 'sound'
etc. types (perhaps even any arbitrary set of MIME content-types?)
- How to rewrite/modify the permission manager + content blocker code so they
don't do the index-to-string-to-index and conversions
- Reprecussions of making changes to the permission manager (i.e. what, if
anything uses it except for the content blocker)

And that's before you get around to writing any UI. At least, that's how I see it.
"you'd think after FOUR YEARS you people would wake up and realise that
1. this is not a priority for the dev team"

I'm not sure who posted that, but IMO, that's a very arrogant answer.
I'd respond: You'd think after 4 years, innumerable comments, votes and
duplicates being submitted, that this really *IS* a priority for users.  

"> there is a very good alternative (adblock extension)"

If users keep posting to this and obviously really want a better or more
integrated fix, then they obviously don't agree that there is an alternative
that *is* good enough, -OR- it's too hard to find that solution.  

Do you accept from the evidence that this is something users want or do you just
act as if 'you know better?'  (yes, I know designers often *do* know better
about what works and what doesn't, but the demand implies that this isn't good
enough for a great many users)

So, is the dev team responsive to what the users want or not?

P.S. If adblock or flashblock or other solutions are so good at answering this,
perhaps they need to be integrated into moz/firefox rather than being separate
extensions.  

(In reply to comment #263)
> If it's just Flash that's the problem, why not just use Flashblock?
> 
> http://flashblock.mozdev.org/

I tried this about half a year ago and found it to be extremely buggy and would
cause Firefox to crash all the time. Then I gave up and went back to adblock.
"I don't want to be annoying about this, as I already mentioned it in #242, but
AdBlock does not avoid flash ads playing themselves, it just hides them
visually, so if the have sound, you still hear it. And as #259 said, this is
getting worse day by day."

Ricardo, is this still true with the latest version?  I use AdBlock to get rid
of a lot of Flash ads, and I've never had an ad that was removed play sounds. 
Also note that, at least in the latest versions, there is an option in the
AdBlock preferences page for "Hide ads" or "Remove ads".  I have "Remove ads"
selected, and that seems to remove all the ads that I don't want.
(In reply to comment #242)
> The latest adblock version I have found just hides flash ads, don't stop them
> before they load, thus wasting bandwith. I want content being blockable at the
> server. To make it worse, flash ad that have sound still play themselves,
> giving the maxium of annoyances.

Are you sure it's flash, and not a sound file embedded as an image or background?

Which is the whole point of this request: it's not just about blocking flash,
but *any* media type. 
(In reply to comment #264)
> Actually, it seems nsContentBlocker uses one of 8 possible values (image,
> script, etc. but not flash or other types)

The magic type is 'object'. flash is loaded as object. Blocking those will block
flash. The downside might be that it will also block java and other plugins.
Depending on the situation that can be good or bad.

> But wait, there's more! When you look into nsPermissionManager you find that
> those strings you pass it end up in another array, whose number of entries is
> limited to 8. Isn't that swell?

If that is not enough, you can always file a bug.

> - When and where are types determined for entities you're about to get from a
> server?

nsIContentPolicy.idl

All those proposed changes are not needed to block flash objects. It works today.
*** Bug 307860 has been marked as a duplicate of this bug. ***
*** Bug 266705 has been marked as a duplicate of this bug. ***
*** Bug 281827 has been marked as a duplicate of this bug. ***
*** Bug 325553 has been marked as a duplicate of this bug. ***
*** Bug 325609 has been marked as a duplicate of this bug. ***
*** Bug 327142 has been marked as a duplicate of this bug. ***
In all the preceding commentary, I don't believe I've seen anyone comment that the blocking of an arbitrary kind of object is an important security feature.  There's another zero day exploit out for WMFs?  In Firefox, do this and you are safe from accidentally loading one from a website.  In Thunderbird do this and your are safe from getting one in e-mail for news.   In SeaMonkey, do this and you are safe.
The problem we have is this:

The hostperm.1 file already supports -- in theory -- a means of accomplishing this. It just doesn't *work*.

See http://kb.mozillazine.org/Hostperm.1 for instructions/details about the hostperm.1 file.

The "object" selector in hostperm.1 *does not block* the <object> tag. (It successfully blocks the <embed> tag, and only that tag.) The "subdocument" selector does, but that's a flawed solution at best, because "subdocument" also blocks framesets and iframes.

Fix that problem, and this bug will be fixed.

cl
(In reply to comment #277)
> The "object" selector in hostperm.1 *does not block* the <object> tag. (It
> successfully blocks the <embed> tag, and only that tag.) The "subdocument"
> selector does, but that's a flawed solution at best, because "subdocument" also
> blocks framesets and iframes.

Which version? On trunk, this should work.
(In reply to comment #278)
> (In reply to comment #277)
> > The "object" selector in hostperm.1 *does not block* the <object> tag. (It
> > successfully blocks the <embed> tag, and only that tag.) The "subdocument"
> > selector does, but that's a flawed solution at best, because "subdocument" also
> > blocks framesets and iframes.
> 
> Which version? On trunk, this should work.

Sorry it took me so long to get back to this. You're right, it works fine in last night's trunk build of Camino. I'll update the KB article to reflect this.

cl


*** Bug 337413 has been marked as a duplicate of this bug. ***
I would really like to see this implemented by Firefox 2.0, or earlier is even better.
Depends on: BlockJS
I vote this to be in the Version => Unspecified category, because I would like
to see this in the Firefox 2.0 Branch.  Really all I want is this:

Right now, users are only able to turn Java/Javascript on or off
completely.  It would be nice to have a UI in Firefox Options to manage Java/Javascript like cookies, pop-ups, and images are currently.  Then, userscould turn Java/Javascript on or off globally, and then specify sites they want to make exceptions for.  

Then, what would be a "nice-to-have" would be if specific Javascript features
could be managed in this same way though the Options menu, but this is just a "nice-to-have" :-).  

And, I've asked on Mozillazine here =>
http://forums.mozillazine.org/viewtopic.php?p=2419927&sid=87af58ee7e52f57d4e45532fb87099a2

I was told that there was already a way to whitelist/blacklist Java/Javascript
by editing prefs.js or about:config, but, yes, I would like to see a decent UI
implemented in Firefox Preferences to manage these rules.


(In reply to comment #282)

> Right now, users are only able to turn Java/Javascript on or off
> completely.  It would be nice to have a UI in Firefox Options to manage
> Java/Javascript like cookies, pop-ups, and images are currently.  Then,
> userscould turn Java/Javascript on or off globally, and then specify sites 
> they want to make exceptions for.  

There's the NoScript plugin to do this. http://www.noscript.net/
(In reply to comment #283)
> (In reply to comment #282)
> 
> > Right now, users are only able to turn Java/Javascript on or off
> > completely.  It would be nice to have a UI in Firefox Options to manage
> > Java/Javascript like cookies, pop-ups, and images are currently.  Then,
> > userscould turn Java/Javascript on or off globally, and then specify sites 
> > they want to make exceptions for.  
> 
> There's the NoScript plugin to do this. http://www.noscript.net/
> 

I know about the NoScript extension can do this (it's extremely popular at that), but I think a browser should just come with these options out of the box.  I'm not necessarily saying, Javascript should be disabled by default though.  

(In reply to comment #284)
> I know about the NoScript extension can do this (it's extremely popular at
> that), but I think a browser should just come with these options out of the
> box.  
I don't agree. I think this should be handled by an extension and doesn't have to be out-of-the-box. 

Also there is the option to pack the NoScript extension with Firefox (disabled or enabled).
(In reply to comment #285)
> I don't agree. I think this should be handled by an extension and doesn't have
> to be out-of-the-box. 

Why? It's just a generalization of an existing feature.
(In reply to comment #285)
> (In reply to comment #284)
> > I know about the NoScript extension can do this (it's extremely popular at
> > that), but I think a browser should just come with these options out of the
> > box.  
> I don't agree. I think this should be handled by an extension and doesn't have
> to be out-of-the-box. 
> 
> Also there is the option to pack the NoScript extension with Firefox (disabled
> or enabled).
> 

I don't think the Noscript extension should be built into Firefox.  It would just look much better if this was built into the preferences menu.  Come on, let's get this done after being reported for 5 years. :)


(In reply to comment #287)
> 
> I don't think the Noscript extension should be built into Firefox.  It would
> just look much better if this was built into the preferences menu.  Come on,
> let's get this done after being reported for 5 years. :)

On the other hand, even the original reporter (that's me) thinks that using AdBlock Plus and Noscript is the way to go.  When I first created this bug, we didn't have either of those extensions, so I wanted the features included in the browser.  But including them in the browser could be constraining to the developers to some degree, and it may also be bad for some of the bundling or distribution deals that the Mozilla org has to make.  The extensions allow everyone to keep doing what they should do, while giving users the ability to block what they want.

The only thing that would help is if these extensions could be made a bit more easily accessible to novice users.  As it is right now, many of them won't know about the extensions.

(In reply to comment #288)
> But including them in the browser could be constraining to the
> developers to some degree, 

I very much doubt that. Is the blocking of images constraining any developers?

> and it may also be bad for some of the bundling or
> distribution deals that the Mozilla org has to make.

That's also unlikely AFAICT, as no blocking will be turned on by default.

> The only thing that would help is if these extensions could be made a bit more
> easily accessible to novice users. 

See Bug 214269 my Bug 326514.
If it is possible to do this for cookies, pop-ups, even something as trivial as images, why not Java and Javascript?  Keep in mind that I'm not necessarily saying Javascript/Java should be disabled by default though.  After 5 years, perhaps the community should really take a good look at this?!  This has got 440 votes in favour!
*** Bug 351947 has been marked as a duplicate of this bug. ***
*** Bug 238388 has been marked as a duplicate of this bug. ***
Disabling plugins is a good way to reduce your attack surface.  I don't like the fact that the discovery of a severe hole in any plugin I use would allow a malicious site to take over my computer.  On the other hand, I'm not about to give up my Strong Bad emails and YouTube videos.

[sg:want P3] - Being able to whitelist sites for use of plugins would allow more users to take this security measure.
Whiteboard: [PL:P3][Plug-in Mgr]see comment 7 for related bugs. see also bug 78104 (pattern-matching blocking) → [sg:want P3][PL:P3][Plug-in Mgr]see comment 7 for related bugs. see also bug 78104 (pattern-matching blocking)
I agree with Jackie, it is alright planning version 3 that's all singing and all dancing but when bug / feature requests that were put in 6 years ago have still not been implimented or even assigned to anyone perhaps it is time for the mozilla foundation to take a step back and think about how they are running the show..... if they are at all :)
Bugzilla is a bug tracking system, not a place for advocacy comments. Please take your advices elsewhere.

The 294 comments here mean that it is very unlikely any real work will be done in this bug. 

See https://bugzilla.mozilla.org/page.cgi?id=etiquette.html - points 1.1 and 1.2 specifically.

(In reply to comment #295)
Cooment 294 is actually advocating making this bug block firefox 3.0, which is a perfectly valid thing to be doing on bugzilla AFACIT.
(In reply to comment #296)
> Comment 294 is actually advocating making this bug block firefox 3.0, which is
> a perfectly valid thing to be doing on bugzilla AFACIT.

Now that's a fine idea! Notice that this bug depends on 38966 which in turn depends on 150872. For those who care, make sure you add your vote on those bugs too!
I'd be happy with "never animate stuff" as a checkbox.
Ducking my head for the tomatoes that may fly:

Doing this is a real mixed bag.  To the extent the goal is for Mozilla browsers to be respected by the web designer community, one wants to leave page layouts alone.  Advertisements fund many, if not most, web efforts.

Animations and sound are a different matter: it seems fair game to limit flash and gif animation (perhaps to one cycle, perhaps with an explicit stop button).  But a general purpose blocker built into the core browser?  It seems antagonistic to the web publisher community.
(In reply to comment #306)
> ..
>  But a general purpose blocker built into the core browser?  It seems
> antagonistic to the web publisher community.
> ..

Not at all. It's just one more freedom for user.


Anybody who would defeat the right of each user to control his own computer is a cracker and should be treated as a criminal, whatever community he's in.  Bleep him.
Re: comment 306

I always thought that we were making the browser for users, not for web publishers.

Maybe I was naive, but all the hours I donated to the project were not supposed to be for web publisher benefit. At least not directly. I really believed that we were building a browser for us, the people.
(In reply to comment #306)

> Doing this is a real mixed bag.  To the extent the goal is for Mozilla browsers
> to be respected by the web designer community, one wants to leave page layouts
> alone.  Advertisements fund many, if not most, web efforts.

Your missing the point: it's not about blocking adverts: Google has a large business with text adverts, and it's one of the reasons they became the top search engine.

It's about blocking intrusive advertisements by companies that use the information of what sites you visit, and about blocking resource-intensive advertisements. Ads use a lot of network and CPU.  This blocks users with limited bandwidth or older computers.

I think some of that is whining about Mozilla-based browsers with ad blockers by web companies when they don't make enough money from advertisers.

> Animations and sound are a different matter: it seems fair game to limit flash
> and gif animation (perhaps to one cycle, perhaps with an explicit stop...

You can do that for animations that the browser plays directly. But you can't control flash or quicktime from outside the plugin.  



(In reply to comment #306)
> ... one wants to leave page layouts alone.

Actually, the inventors of HTML wanted the _viewer_ of a web-page to determine the layout!

And I'm sick and tired of those immature, self-proclaimed "web designers" that want to tell me at which size and in which colour I'm supposed to read text... oh wait... text was a luxury that got replaced by ugly, flashing images with little to none information content.
Firefox previousl blocked Flash content automatically, allowing the user to decide if they wanted to view the obnoxious content. Now users can't even remove the action of  even allowing Flash content (SWF) files when attempting to configure their Firefox settings. This is annoying, extremely so! I used to surf exclusively with Firefox for this reason alone - I don't want Flash content jammed down my throat. Why are you enabling them to do so when formerly you did not?! Firefox needs to fix this IMMEDIATELY.
(In reply to comment #314)
> Firefox previousl blocked Flash content automatically, allowing the user to
> decide if they wanted to view the obnoxious content.

AFAIK, Firefox never provided such an option. You can use the Flashblock extension in the mean time. It makes some sites think that Flash is not supported (unless you whitelist them), but there would probably be the same problem if Firefox had this option.
Vincent is right. Therefore, please install FlashBlock from http://flashblock.mozdev.org/ and in future try to avoid spamming mozilla bugs.
(In reply to comment #316)

Indeed. Here are some other popular, related extensions.

Adblock Plus: https://addons.mozilla.org/en-US/firefox/addon/1865

NoScript: https://addons.mozilla.org/en-US/firefox/addon/722

These have been mentioned in previous comments, but I thought it might be helpful to provide current links.
to comment #317

Addon 722 is to strong - because it's a script which puts the blinking cursor into the first entry-field of a form or in the search-line of a search-engine or a dictionary...
To loose this functionality cannot be the goal!

Firefox automatically starts to play sounds if embedded in a web-page and if
installed realplayer or other plugins.
This is not nice. 
There is a need for preferences to say „ask before starting
sounds" and „ask before starting plugins“ (or "block sounds" - because "asking" could cause to many "questions") and maybe this should be possible for several plugins like flashplayer, realplayer and so on.

The default can be running everything, but the user must get the possibility to decide, what he wants!

Flashblock (addon 433) is (just) one step in the right direction.
Blocks: 485488
Flags: wanted-fennec1.0?
Flags: blocking1.9.0.19?
This doesn't block 1.9.0.19, no.
Flags: blocking1.9.0.19? → blocking1.9.0.19-
20:07:39:185: Warning: Expected color but found 'invert'.  Error in parsing value for 'outline-color'.  Declaration dropped. Source File: http://apps.facebook.com/onthefarm/index.php?ref=bookmarks Line: 569, Column: 93 Category: CSS Parser 

<< I always Got this Error everytime, when loading Game Application On Facebook .. 
If anyone can help me to fix this error.. I'll appreciate it.. 

thanks
Flags: in-testsuite+
Flags: in-litmus+
Comment on attachment 130874 [details]
plugin-blocker.js (v.03)

Not a patch, unmarking patch status.
Attachment #130874 - Attachment is patch: false
Clearing in‑testsuite:+ and in‑litmus:+ flags erroneously set just now by mr.ravii2020.

Please don't change flags if you don't know what they mean.
Flags: in-testsuite+
Flags: in-litmus+
I think this is [parity-ie] based on
http://blogs.msdn.com/b/ie/archive/2011/02/28/activex-filtering-for-consumers.aspx
Whiteboard: [sg:want P3][PL:P3][Plug-in Mgr]see comment 7 for related bugs. see also bug 78104 (pattern-matching blocking) → [sg:want P3][PL:P3][Plug-in Mgr][parity-IE]see comment 7 for related bugs. see also bug 78104 (pattern-matching blocking)
I guess I voted for this feature mainly for whitelist to enable Java.
It seems to me that all the new versions of, and extensions to, HTML since at least HTML 2.0 have not really been about creating new capabilities that browser users would consider useful, but rather have mostly been about making it harder to block whatever behavior a web site designer wants to inflict on your screen or your computer.  If I could, I would want to limit every such new capability -- Java, other scripting languages, Flash, and so on -- to whitelisted sites only.

This seems to me the purpose of, and need for, this bug.
Anson Ng wrote:

> I guess I voted for this feature mainly for whitelist to enable Java.

Please give NoScript a try.

https://addons.mozilla.org/en-US/firefox/addon/noscript/
http://noscript.net/features
Basic browser features keep getting pushed off into third-party plugins, then when the browser is slow and crashes, it's blamed on the plugins. Chrome offers this feature and a firebug-like feature as part of the basic package, and is faster and more stable. Byezilla.
I would like to add my vote and to agree with John David Galt
Bill
http://www.cs.ucl.ac.uk/staff/W.Langdon/
Firefox 17 implements "Click-to-play blocklisting".

https://www.mozilla.org/en-US/firefox/17.0/releasenotes/
https://blog.mozilla.org/addons/2012/10/11/click-to-play-coming-firefox-17/

It seems an end-user could use this facilty to block any media type?
@Mason: Agreed.  The capability is already in FF.  If your plugin is on the blocked list, you can explicitly allow it once, permanently whitelist it for specific sites.

In other words, the feature is already supported.  There's just no UI to access it.  Someone needs to make the following changes:

1: Allow users to add entries to the list of blocked plugins, which would treat them as unsafe even if they're not on Mozilla's list.  This should allow you to specify versions or to block them for all versions.  Of course, you should not be able to edit or remove entries from Mozilla's list - you should only be able to edit/remove locally-added entries.

2: Provide a way to edit the whitelist of permitted sites associated with blocked plugins (both user-added and Mozilla-added.)  This way, you can resume blocking a site when you're done using it and you can pre-whitelist a site you know you're going to be accessing in the future.

All the rest of the infrastructure appears to already be in FF.
(In reply to David Charlap from comment #339)
> 1: Allow users to add entries to the list of blocked plugins

bug 549697 will add UI to toggle click-to-play for each plugin in the plugin list in about:addons.

> 2: Provide a way to edit the whitelist of permitted sites associated with
> blocked plugins (both user-added and Mozilla-added.)

about:permissions and "Page Info" (click the lock/globe in the urlbar, click "More Information...", click "Permissions") have some UI to handle this. These will be improved in bug 775857 and bug 821892.

You might also be interested in bug 825438.
@DavidK: Thanks much.  I'm glad to read that the devs are way ahead of me here.  I look forward to the feature's completion.
As filed, this bug isn't directly about plugins. If it is, then I'd just mark it a dup of bug 549697 which we're working on. Otherwise, this should be in an extension.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
No longer blocks: 229196
Keywords: sec-want
Whiteboard: [sg:want P3][PL:P3][Plug-in Mgr][parity-IE]see comment 7 for related bugs. see also bug 78104 (pattern-matching blocking) → [PL:P3][Plug-in Mgr][parity-IE]see comment 7 for related bugs. see also bug 78104 (pattern-matching blocking)
Flags: wanted-fennec1.0?
Flags: blocking1.9.0.19-
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: