Last Comment Bug 94035 - (BlockFlash) Allow blocking of any media type (flash, plug-in, applet, etc.) by site (like cookies and images)
(BlockFlash)
: Allow blocking of any media type (flash, plug-in, applet, etc.) by site (like...
Status: RESOLVED WONTFIX
[PL:P3][Plug-in Mgr][parity-IE]see co...
:
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: All All
: P4 enhancement with 445 votes (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 70805 74256 74754 103791 107126 107207 107345 109515 129460 144961 146437 147829 148534 153427 156283 156970 158259 158341 159401 159437 160341 162334 162913 163895 163902 166559 166760 168212 170367 172034 175256 175736 176752 178124 178129 180479 182763 183019 184179 184699 189195 189560 191771 193972 193992 194101 198222 201958 202989 205188 210255 212368 214246 215542 220955 222121 225568 225957 227413 228951 229840 230472 230682 232961 232962 233010 233679 234098 234152 235433 237232 237379 238388 240838 243016 244456 245452 246730 254091 260738 264220 266705 270460 270977 274418 276322 276348 276765 281827 286658 292509 307860 325553 325609 327142 337413 351947 373711 376271 377977 380701 384636 402003 406912 426188 441715 461753 576032 753346 (view as bug list)
Depends on: BlockJS 240070
Blocks: 147866 485488 useragent 98995
  Show dependency treegraph
 
Reported: 2001-08-06 18:32 PDT by Warner Young
Modified: 2016-07-15 16:25 PDT (History)
251 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Problem - unable to get flash pop-up info for entry into add blocker. (162 bytes, text/plain)
2002-11-22 19:05 PST, Warren Severin
no flags Details
plugin-blocker.js (v.03) (5.96 KB, text/plain)
2003-09-03 16:39 PDT, Peter Lubczynski
no flags Details
patch v1 (8.99 KB, patch)
2003-12-06 07:48 PST, Michiel van Leeuwen (email: mvl+moz@)
no flags Details | Diff | Splinter Review
mock-up example of in-page plug-in handling and allowed-sites plug-in gui (17.47 KB, image/png)
2004-06-19 17:51 PDT, example
no flags Details
mock-up example of in-page plug-in handling and allowed-sites plug-in gui (17.47 KB, image/png)
2004-06-19 17:54 PDT, example
no flags Details
Tons of Error Console file accepted. (239 bytes, text/plain)
2010-10-01 06:17 PDT, Sandy Rahmat Hidayat
no flags Details

Description Warner Young 2001-08-06 18:32:13 PDT
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".
Comment 1 timeless 2001-08-07 05:53:10 PDT
it probably is a dupe...
Comment 2 Christopher Aillon (sabbatical, not receiving bugmail) 2001-08-09 00:38:40 PDT
Bug 85621 is similar, but more specific.  Other than that, I came up empty on a
query.
Comment 3 Greg K. 2001-08-30 19:25:53 PDT
So, this would be about a generic abillity to block an arbitrary MIME type from an 
arbitrary server?
Comment 4 Warner Young 2001-08-30 22:14:31 PDT
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?
Comment 5 Greg K. 2001-09-04 18:09:17 PDT
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.
Comment 6 Warner Young 2001-09-20 15:01:12 PDT
Possibly a dupe of bug 24418?  At least, they seem to have somewhat similar goals.
Comment 7 Jesse Ruderman 2001-09-20 16:26:29 PDT
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
Comment 8 Prisacari Sergey 2001-09-25 05:15:14 PDT
70805 [REF] implement Macromedia Flash blocker
Comment 9 Matthew Paul Thomas 2001-10-19 06:57:07 PDT
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.
Comment 10 Niels Aufbau 2001-10-23 02:02:41 PDT
Throw in "all" as a choice for the media-type, and you have the ability to
completely blacklist an annoying site (bug 33469).
Comment 11 R.K.Aa. 2001-10-27 08:43:01 PDT
*** Bug 107126 has been marked as a duplicate of this bug. ***
Comment 12 Cormac F 2001-10-29 07:48:44 PST
*** Bug 107345 has been marked as a duplicate of this bug. ***
Comment 13 Christopher Aillon (sabbatical, not receiving bugmail) 2001-11-10 07:10:12 PST
*** Bug 109515 has been marked as a duplicate of this bug. ***
Comment 14 Quinn Yost (mythdraug) 2001-12-02 18:53:57 PST
Well, I just ran into my first Flash advertisement.  This seems
like a useful idea to me now.

Comment 15 Jesse Ruderman 2001-12-02 21:51:41 PST
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.)
Comment 16 Benoit 2002-01-17 08:40:25 PST
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.
Comment 17 Warner Young 2002-01-17 10:47:41 PST
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.
Comment 18 Bertilo Wennergren 2002-04-05 06:15:51 PST
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.
Comment 19 Raphael Wegmann 2002-04-05 11:49:31 PST
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
Comment 20 Garth Wallace 2002-04-05 23:15:02 PST
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.
Comment 21 Simon Spiegel 2002-04-06 00:27:42 PST
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.
Comment 22 Warner Young 2002-04-06 00:34:15 PST
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.
Comment 23 Garth Wallace 2002-04-06 11:36:08 PST
Ah, sorry. My bad.
Comment 24 James Paige 2002-05-23 11:26:19 PDT
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?

Comment 25 Warner Young 2002-05-23 12:17:02 PDT
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 :)
Comment 26 Sagie Maoz 2002-05-23 18:37:10 PDT
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.
Comment 27 Sagie Maoz 2002-05-23 18:44:36 PDT
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.
Comment 28 Stephen P. Morse 2002-05-23 19:05:11 PDT
Isn't that what the http HEAD method is all about?
Comment 29 Brian Rogers 2002-06-08 16:09:15 PDT
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.
Comment 30 Vincent Lefevre 2002-06-08 16:28:26 PDT
If Mozilla first gets the HTTP headers, it doesn't necessarily have to load the URL.
Comment 31 Garth Wallace 2002-06-09 00:11:43 PDT
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.
Comment 32 Brian Rogers 2002-06-09 14:23:14 PDT
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.
Comment 33 lode leroy 2002-06-10 01:25:27 PDT
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'

Comment 34 Simon Spiegel 2002-06-10 02:23:26 PDT
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?
Comment 35 Sander 2002-06-10 02:40:07 PDT
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*
Comment 36 Peter Lubczynski 2002-06-10 14:26:18 PDT
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?
Comment 37 Graham 2002-06-15 05:47:37 PDT
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.
Comment 38 Sagie Maoz 2002-06-15 09:11:25 PDT
gknap@uoguelph.ca - This is requested in Bug 78104.
Comment 39 Mikko Virkkilä 2002-06-16 23:19:10 PDT
Does this bug block on Buf 152245 or are they duplicates?
Comment 40 Matthew Paul Thomas 2002-07-03 06:48:33 PDT
*** Bug 70805 has been marked as a duplicate of this bug. ***
Comment 41 Alfonso Martinez 2002-07-08 10:42:32 PDT
*** Bug 156283 has been marked as a duplicate of this bug. ***
Comment 42 Alfonso Martinez 2002-07-11 13:23:28 PDT
*** Bug 156970 has been marked as a duplicate of this bug. ***
Comment 43 Wesha 2002-07-19 10:53:23 PDT
*** Bug 158341 has been marked as a duplicate of this bug. ***
Comment 44 Jesse Ruderman 2002-07-19 17:13:22 PDT
*** Bug 158259 has been marked as a duplicate of this bug. ***
Comment 45 Jesse Ruderman 2002-07-23 14:49:39 PDT
You can use the "zap embeds" bookmarklet to remove flash/java/iframe ads from a 
single page.  http://www.squarefree.com/bookmarklets/zap.html
Comment 46 Jo Hermans 2002-07-25 12:00:02 PDT
*** Bug 159401 has been marked as a duplicate of this bug. ***
Comment 47 Jo Hermans 2002-07-25 14:45:31 PDT
*** Bug 159437 has been marked as a duplicate of this bug. ***
Comment 48 Alfonso Martinez 2002-07-31 11:03:41 PDT
*** Bug 160341 has been marked as a duplicate of this bug. ***
Comment 49 Stephen Walker 2002-08-12 11:42:36 PDT
*** Bug 162334 has been marked as a duplicate of this bug. ***
Comment 50 Mats Palmgren (:mats) 2002-08-15 14:30:17 PDT
*** Bug 162913 has been marked as a duplicate of this bug. ***
Comment 51 Jo Hermans 2002-08-21 11:07:22 PDT
*** Bug 163895 has been marked as a duplicate of this bug. ***
Comment 52 Alfonso Martinez 2002-08-21 13:13:05 PDT
*** Bug 163902 has been marked as a duplicate of this bug. ***
Comment 53 Jo Hermans 2002-09-04 06:31:15 PDT
*** Bug 166559 has been marked as a duplicate of this bug. ***
Comment 54 Daniel Wang 2002-09-04 08:06:39 PDT
chg summary based on duplicate summaries to make this bug easier to
find
Comment 55 Jo Hermans 2002-09-04 23:52:01 PDT
*** Bug 166760 has been marked as a duplicate of this bug. ***
Comment 56 James (bugzilla2 to jamesd atserver spamgourmet net 2002-09-06 06:20:07 PDT
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.
Comment 57 Jo Hermans 2002-09-12 07:52:30 PDT
*** Bug 168212 has been marked as a duplicate of this bug. ***
Comment 58 Jo Hermans 2002-09-23 14:19:12 PDT
*** Bug 170367 has been marked as a duplicate of this bug. ***
Comment 59 Dave 2002-09-24 10:16:41 PDT
I'm really sick of those stupid ads where some SUV perpetually speeds across my
browser and pegs my cpu. Voting for this.
Comment 60 HyperHacker 2002-09-24 14:19:03 PDT
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.
Comment 61 R.K.Aa. 2002-10-01 17:39:09 PDT
*** Bug 172034 has been marked as a duplicate of this bug. ***
Comment 62 Warner Young 2002-10-18 12:05:13 PDT
*** Bug 175256 has been marked as a duplicate of this bug. ***
Comment 63 flyguy 2002-10-20 16:13:00 PDT
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.
Comment 64 Ashley Bischoff (blog at handcoding.com) 2002-10-20 20:38:22 PDT
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).
Comment 65 Jo Hermans 2002-10-21 04:22:07 PDT
*** Bug 175736 has been marked as a duplicate of this bug. ***
Comment 66 WD 2002-10-25 12:29:07 PDT
*** Bug 176752 has been marked as a duplicate of this bug. ***
Comment 67 jason 2002-10-25 14:02:04 PDT
I absolutely can not stand flash advertisments.  I want the ability to block
them....immediately!
Comment 68 Mike Shaver (:shaver -- probably not reading bugmail closely) 2002-10-25 14:12:10 PDT
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.
Comment 69 Ren Hoek 2002-10-31 03:17:46 PST
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.
Comment 70 Zibi Braniecki [:gandalf][:zibi] 2002-10-31 04:20:17 PST
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.
Comment 71 Christopher Wanko 2002-10-31 05:24:38 PST
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.

Comment 72 Zibi Braniecki [:gandalf][:zibi] 2002-10-31 06:02:59 PST
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)
Comment 73 Dave 2002-10-31 07:45:08 PST
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.
Comment 74 Ren Hoek 2002-10-31 08:03:53 PST
>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.
Comment 75 Philip Nemec 2002-10-31 08:58:20 PST
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.
Comment 76 Nahor 2002-10-31 09:16:04 PST
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.
Comment 77 adam howard 2002-10-31 09:27:57 PST
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? :)
Comment 78 av (gone) 2002-10-31 09:33:14 PST
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.
Comment 79 Zibi Braniecki [:gandalf][:zibi] 2002-10-31 12:38:44 PST
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
Comment 80 Vincent Lefevre 2002-11-01 03:10:03 PST
Popup should also be blocked (by sub-URL/regexp). And IFRAME.
Comment 81 Zibi Braniecki [:gandalf][:zibi] 2002-11-01 09:59:12 PST
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.
Comment 82 Zibi Braniecki [:gandalf][:zibi] 2002-11-01 10:01:03 PST
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.
Comment 83 David Hagood 2002-11-01 10:11:29 PST
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....
Comment 84 Vincent Lefevre 2002-11-01 10:18:30 PST
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).
Comment 85 HJ 2002-11-01 13:31:36 PST
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.
Comment 86 Zibi Braniecki [:gandalf][:zibi] 2002-11-01 13:43:24 PST
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'.
Comment 87 rubydoo123 2002-11-01 16:39:53 PST
I believe this will be incorporated with the plug-in manager work being
addressed within the plug-ins team, reassinging
Comment 88 Dave 2002-11-01 17:07:21 PST
DOH! :-(
Comment 89 Matthias Versen [:Matti] 2002-11-02 20:12:52 PST
*** Bug 178124 has been marked as a duplicate of this bug. ***
Comment 90 Matthias Versen [:Matti] 2002-11-02 21:24:08 PST
*** Bug 178129 has been marked as a duplicate of this bug. ***
Comment 91 JoSH Lehan 2002-11-10 18:59:48 PST
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");})();
Comment 92 Zibi Braniecki [:gandalf][:zibi] 2002-11-11 08:28:09 PST
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!
Comment 93 Nahor 2002-11-11 08:50:56 PST
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.
Comment 94 Zibi Braniecki [:gandalf][:zibi] 2002-11-11 09:06:05 PST
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.
Comment 95 adam howard 2002-11-11 10:01:31 PST
"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*
Comment 96 Mike Shaver (:shaver -- probably not reading bugmail closely) 2002-11-11 10:09:33 PST
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.)
Comment 97 Christopher Wanko 2002-11-11 10:31:36 PST
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?




Comment 98 Nahor 2002-11-11 10:42:17 PST
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. 
Comment 99 Steven Grimm 2002-11-14 18:28:03 PST
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).
Comment 100 Matthias Versen [:Matti] 2002-11-16 09:49:57 PST
*** Bug 180479 has been marked as a duplicate of this bug. ***
Comment 101 Shoshannah Forbes 2002-11-16 09:55:46 PST
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.
Comment 102 Warren Severin 2002-11-22 19:05:32 PST
Created attachment 107203 [details]
Problem - unable to get flash pop-up info for entry into add blocker.

If cannot block from Mozilla, then at least let the info be retrieved for entry
into an ad blocker.
Comment 103 Fernando Cassia 2002-11-24 01:58:49 PST
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
Comment 104 JoSH Lehan 2002-11-25 21:09:04 PST
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.
Comment 105 Ubermonkey 2002-11-26 05:36:46 PST
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.
Comment 106 Fernando Cassia 2002-11-26 12:12:40 PST
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?
Comment 107 R.K.Aa. 2002-12-02 08:34:19 PST
*** Bug 183019 has been marked as a duplicate of this bug. ***
Comment 108 Garrett Smith 2002-12-07 07:17:51 PST
Yeah. Let us block flash. I hate flash.
Comment 109 Shanti Rao 2002-12-07 14:35:25 PST
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.
Comment 110 Asa Dotzler [:asa] 2002-12-08 00:14:49 PST
*** Bug 184179 has been marked as a duplicate of this bug. ***
Comment 111 André Dahlqvist 2002-12-19 07:05:57 PST
*** Bug 184699 has been marked as a duplicate of this bug. ***
Comment 112 Justin Kerk 2003-01-07 12:40:20 PST
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.
Comment 113 Olivier Cahagne 2003-01-15 07:07:53 PST
*** Bug 189195 has been marked as a duplicate of this bug. ***
Comment 114 Alex Bishop 2003-01-17 21:32:57 PST
*** Bug 189560 has been marked as a duplicate of this bug. ***
Comment 115 serge (gone) 2003-01-21 10:12:41 PST
--> peterl
Comment 116 Alfonso Martinez 2003-02-03 12:52:48 PST
*** Bug 191771 has been marked as a duplicate of this bug. ***
Comment 117 Peter Lubczynski 2003-02-10 12:04:17 PST
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.
Comment 118 timeless 2003-02-10 13:07:11 PST
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>
Comment 119 Heikki Toivonen (remove -bugzilla when emailing directly) 2003-02-10 15:20:27 PST
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...
Comment 120 R.K.Aa. 2003-02-19 01:42:01 PST
*** Bug 193992 has been marked as a duplicate of this bug. ***
Comment 121 gavin long 2003-02-19 13:12:06 PST
*** Bug 194101 has been marked as a duplicate of this bug. ***
Comment 122 R.K.Aa. 2003-03-19 07:32:35 PST
*** Bug 198222 has been marked as a duplicate of this bug. ***
Comment 123 Jesse Ruderman 2003-03-20 03:32:55 PST
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.
Comment 124 Matthew Smyth 2003-03-31 11:40:33 PST
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?
Comment 125 Philip Nemec 2003-03-31 12:11:19 PST
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.
Comment 126 Jey 2003-03-31 12:22:58 PST
That's a great idea Philip!

It sounds simple and elegant.  Is it?   What would be the hurdles to
accomplishing this type of solution?
Comment 127 Mike Shaver (:shaver -- probably not reading bugmail closely) 2003-03-31 13:25:17 PST
Isn't that basically what Jesse has done, and described in comment 123?
Comment 128 Philip Nemec 2003-03-31 13:35:28 PST
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!
Comment 129 Peter Lubczynski 2003-04-03 14:07:35 PST
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. 
Comment 130 James Stauffer 2003-04-07 10:18:28 PDT
Optionally loading specific countent would be good. (Similar to MS IE Show picture.)
Comment 131 Justin Kerk 2003-04-07 11:30:25 PDT
Show image already exists as bug 47475.
Comment 132 James Stauffer 2003-04-07 11:54:16 PDT
Optionally loading specific content would be nice for any media type (not just
images).
Comment 133 Sébastien Delahaye 2003-04-14 06:47:39 PDT
*** Bug 201958 has been marked as a duplicate of this bug. ***
Comment 134 Bartosz Wucke 2003-04-18 17:02:57 PDT
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)" ? 
Comment 135 Jesse Ruderman 2003-04-19 03:07:04 PDT
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).
Comment 136 Matthias Versen [:Matti] 2003-04-22 19:46:18 PDT
*** Bug 202989 has been marked as a duplicate of this bug. ***
Comment 137 Alex Bishop 2003-05-10 13:53:22 PDT
*** Bug 205188 has been marked as a duplicate of this bug. ***
Comment 138 Jozef Riha 2003-06-03 05:47:46 PDT
hmmm, what about this: http://ted.mielczarek.org/code/mozilla/
Comment 139 Adam M. Costello 2003-06-08 04:48:09 PDT
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.
Comment 140 Adam M. Costello 2003-06-08 12:36:44 PDT
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.
Comment 141 Michiel van Leeuwen (email: mvl+moz@) 2003-06-14 08:09:10 PDT
Adam, you just described nsIContentPolicy. So the backend is there. Look at
nsImgManager to see how this can work.
Comment 142 Adam M. Costello 2003-06-14 10:58:48 PDT
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.
Comment 143 Michiel van Leeuwen (email: mvl+moz@) 2003-06-14 14:42:25 PDT
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.
Comment 144 Peter Lubczynski 2003-06-16 11:13:47 PDT
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.
Comment 145 beanladen 2003-06-18 12:00:30 PDT
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 !
Comment 146 Christopher Aillon (sabbatical, not receiving bugmail) 2003-06-22 01:35:44 PDT
*** Bug 210255 has been marked as a duplicate of this bug. ***
Comment 147 paul stanton 2003-07-10 21:19:13 PDT
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
Comment 148 Charles Fenwick 2003-07-10 21:28:59 PDT
*** Bug 212368 has been marked as a duplicate of this bug. ***
Comment 149 L.G. 2003-07-25 12:29:15 PDT
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.
Comment 150 Scott A. Colcord 2003-07-25 13:17:17 PDT
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.
Comment 151 Simon Spiegel 2003-07-25 13:26:33 PDT
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.
Comment 152 Kjetil Helle 2003-07-25 14:07:54 PDT
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.
Comment 153 timeless 2003-07-25 14:46:13 PDT
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.
Comment 154 Charles Fenwick 2003-07-28 21:45:50 PDT
*** Bug 214246 has been marked as a duplicate of this bug. ***
Comment 155 Bill Mason 2003-08-08 08:42:45 PDT
*** Bug 215542 has been marked as a duplicate of this bug. ***
Comment 156 K.H. Pennemann 2003-08-22 11:08:54 PDT
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
Comment 157 K.H. Pennemann 2003-09-03 05:05:08 PDT
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.
------------------------------------
Comment 158 Hermann Schwab 2003-09-03 16:20:50 PDT
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...
Comment 159 Peter Lubczynski 2003-09-03 16:39:25 PDT
Created attachment 130874 [details]
plugin-blocker.js (v.03)

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.
Comment 160 paul stanton 2003-09-07 21:58:30 PDT
a link that may be useful to those losing patience:
http://texturizer.net/firebird/adblock.html
Comment 161 JoSH Lehan 2003-09-07 23:15:34 PDT
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.
Comment 162 johann.petrak@gmail.com 2003-09-07 23:52:28 PDT
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)
Comment 163 HJ 2003-09-08 01:15:06 PDT
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...
Comment 165 Jo Hermans 2003-10-01 14:30:19 PDT
*** Bug 220955 has been marked as a duplicate of this bug. ***
Comment 166 Olivier Cahagne 2003-10-14 09:22:09 PDT
*** Bug 222121 has been marked as a duplicate of this bug. ***
Comment 167 thesh_bugs 2003-10-17 14:12:38 PDT
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.
Comment 168 Hao Huang 2003-11-12 13:31:46 PST
Will this feature ever be implemented?  There are a lot of talking on this bug
but it is still NEW, after 2+ years.
Comment 169 Ron Thigpen 2003-11-12 13:56:15 PST
Those waiting for these features may wish to try the AdBlock extension. 
see: <http://adblock.mozdev.org/>
Comment 170 Alfonso Martinez 2003-11-13 07:27:45 PST
*** Bug 225568 has been marked as a duplicate of this bug. ***
Comment 171 Gilles Durys 2003-11-17 05:27:09 PST
*** Bug 225957 has been marked as a duplicate of this bug. ***
Comment 172 Warner Young 2003-12-03 17:21:37 PST
*** Bug 227413 has been marked as a duplicate of this bug. ***
Comment 173 Ted 2003-12-04 07:07:20 PST
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.
Comment 174 Oleg Dulin 2003-12-04 08:16:38 PST
I have to agree with the previous poster.

Two years and this bug still hasn't been addressed yet.
Comment 175 Mike Shaver (:shaver -- probably not reading bugmail closely) 2003-12-04 08:41:59 PST
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.
Comment 176 Michiel van Leeuwen (email: mvl+moz@) 2003-12-06 07:48:32 PST
Created attachment 136933 [details] [diff] [review]
patch v1

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....)
Comment 177 Zach 2003-12-29 14:58:05 PST
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.
Comment 178 Garth Wallace 2003-12-29 19:05:56 PST
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.
Comment 179 Olivier Cahagne 2004-01-01 08:21:22 PST
*** Bug 229840 has been marked as a duplicate of this bug. ***
Comment 180 Oleg Sidletskiy 2004-01-08 21:22:42 PST
*** Bug 230472 has been marked as a duplicate of this bug. ***
Comment 181 Bertrand Denoix 2004-01-12 14:13:58 PST
*** Bug 230682 has been marked as a duplicate of this bug. ***
Comment 182 Jo Hermans 2004-02-03 04:19:17 PST
*** Bug 232962 has been marked as a duplicate of this bug. ***
Comment 183 Boris Zbarsky [:bz] (TPAC) 2004-02-03 09:04:04 PST
*** Bug 232961 has been marked as a duplicate of this bug. ***
Comment 184 Oleg Sidletskiy 2004-02-03 18:16:58 PST
*** Bug 233010 has been marked as a duplicate of this bug. ***
Comment 185 Oleg Sidletskiy 2004-02-03 19:41:51 PST
*** Bug 193972 has been marked as a duplicate of this bug. ***
Comment 186 Oleg Dulin 2004-02-08 15:12:26 PST
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...
Comment 187 Oleg Dulin 2004-02-08 15:13:31 PST
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...
Comment 188 Michiel van Leeuwen (email: mvl+moz@) 2004-02-08 15:18:01 PST
Oleg, did you read the bug? Did you see the javascript component? Did you see
the patch, wating for review?
Comment 189 Jeff Walden [:Waldo] (remove +bmo to email) 2004-02-10 20:12:33 PST
*** Bug 233679 has been marked as a duplicate of this bug. ***
Comment 190 Gilles Durys 2004-02-13 04:26:21 PST
*** Bug 234152 has been marked as a duplicate of this bug. ***
Comment 191 Dave Miller [:justdave] (justdave@bugzilla.org) 2004-02-13 10:12:18 PST
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.
Comment 192 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2004-02-13 12:54:48 PST
God this bug generates a lot of spam!
Comment 193 Jo Hermans 2004-02-24 07:55:10 PST
*** Bug 235433 has been marked as a duplicate of this bug. ***
Comment 194 Karl Pauls 2004-03-01 09:20:55 PST
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>.
Comment 195 Markus Gaugusch 2004-03-02 03:20:20 PST
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 :-)
Comment 196 Kelley Cook 2004-03-02 12:08:09 PST
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.
Comment 197 johann.petrak@gmail.com 2004-03-02 16:11:14 PST
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. 
Comment 198 Warner Young 2004-03-02 17:01:31 PST
(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.
Comment 199 Mauro Cicognini 2004-03-03 09:38:36 PST
(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.
Comment 200 Thomas Schumm 2004-03-03 23:11:21 PST
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.
Comment 201 basic 2004-03-03 23:21:52 PST
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.
Comment 202 Michiel van Leeuwen (email: mvl+moz@) 2004-03-04 00:16:44 PST
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.
Comment 203 Warner Young 2004-03-11 23:38:28 PST
*** Bug 237232 has been marked as a duplicate of this bug. ***
Comment 204 Simon Paquet [:sipaq] 2004-03-15 08:01:20 PST
*** Bug 237379 has been marked as a duplicate of this bug. ***
Comment 205 Simon Paquet [:sipaq] 2004-03-16 15:23:01 PST
*** Bug 234098 has been marked as a duplicate of this bug. ***
Comment 206 José Jeria 2004-04-18 04:38:58 PDT
*** Bug 240838 has been marked as a duplicate of this bug. ***
Comment 207 Michiel van Leeuwen (email: mvl+moz@) 2004-04-30 05:42:54 PDT
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
Comment 208 Michiel van Leeuwen (email: mvl+moz@) 2004-05-08 07:25:18 PDT
*** Bug 243016 has been marked as a duplicate of this bug. ***
Comment 209 christian 2004-05-16 07:15:47 PDT
I agree, i'd like to be able to block flash ads too.
Comment 210 Bill Mason 2004-05-23 15:59:06 PDT
*** Bug 244456 has been marked as a duplicate of this bug. ***
Comment 211 Jo Hermans 2004-06-03 04:38:10 PDT
*** Bug 245452 has been marked as a duplicate of this bug. ***
Comment 212 Bogdan Stroe 2004-06-19 10:25:31 PDT
*** Bug 246730 has been marked as a duplicate of this bug. ***
Comment 213 example 2004-06-19 17:51:35 PDT
Created attachment 151253 [details]
mock-up example of in-page plug-in handling and allowed-sites plug-in gui

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!
Comment 214 example 2004-06-19 17:54:33 PDT
Created attachment 151255 [details]
mock-up example of in-page plug-in handling and allowed-sites plug-in gui

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!
Comment 215 example 2004-06-19 17:57:42 PDT
oops, sorry dupe.
Comment 216 Aaron Leventhal 2004-06-19 18:35:56 PDT
(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.
Comment 217 Patrick 2004-07-05 04:35:49 PDT
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
Comment 218 Michiel van Leeuwen (email: mvl+moz@) 2004-07-05 10:36:05 PDT
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.
Comment 219 Olivier Cahagne 2004-09-21 03:24:45 PDT
*** Bug 260738 has been marked as a duplicate of this bug. ***
Comment 220 Stefan Borggraefe 2004-10-13 12:14:44 PDT
*** Bug 264220 has been marked as a duplicate of this bug. ***
Comment 221 Uri Bernstein (Google) 2004-11-20 10:24:07 PST
*** Bug 270977 has been marked as a duplicate of this bug. ***
Comment 222 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-12-23 14:29:07 PST
*** Bug 153427 has been marked as a duplicate of this bug. ***
Comment 223 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-12-23 14:29:14 PST
*** Bug 148534 has been marked as a duplicate of this bug. ***
Comment 224 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-12-23 14:29:16 PST
*** Bug 146437 has been marked as a duplicate of this bug. ***
Comment 225 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-12-23 14:29:17 PST
*** Bug 147829 has been marked as a duplicate of this bug. ***
Comment 226 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-12-23 14:29:24 PST
*** Bug 144961 has been marked as a duplicate of this bug. ***
Comment 227 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-12-23 14:29:34 PST
*** Bug 129460 has been marked as a duplicate of this bug. ***
Comment 228 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-12-23 14:29:36 PST
*** Bug 107207 has been marked as a duplicate of this bug. ***
Comment 229 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-12-23 14:29:49 PST
*** Bug 103791 has been marked as a duplicate of this bug. ***
Comment 230 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-12-23 14:30:02 PST
*** Bug 74256 has been marked as a duplicate of this bug. ***
Comment 231 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-12-23 14:30:07 PST
*** Bug 74754 has been marked as a duplicate of this bug. ***
Comment 232 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-12-29 00:57:49 PST
*** Bug 276322 has been marked as a duplicate of this bug. ***
Comment 233 Jo Hermans 2004-12-29 06:28:44 PST
*** Bug 276348 has been marked as a duplicate of this bug. ***
Comment 234 Jo Hermans 2005-01-02 13:56:25 PST
*** Bug 276765 has been marked as a duplicate of this bug. ***
Comment 235 Boris Zbarsky [:bz] (TPAC) 2005-01-16 22:29:20 PST
*** Bug 274418 has been marked as a duplicate of this bug. ***
Comment 236 Steve Kelem 2005-02-16 14:30:18 PST
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 237 Scott A. Colcord 2005-02-16 15:14:18 PST
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.  :-)
Comment 238 Steve Kelem 2005-02-17 09:02:13 PST
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
Comment 239 Warner Young 2005-02-17 11:40:59 PST
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.
Comment 240 Igor Velkov 2005-02-18 03:52:15 PST
So, why don't change bug state to WONTFIX?
Comment 241 Patrik Spieß 2005-02-18 04:03:53 PST
(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).
Comment 242 Ricardo Sánchez-Sáez 2005-02-18 09:10:42 PST
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.)
Comment 243 jeff wilkinson 2005-02-18 09:22:54 PST
If adblock doesn't fit this bug, have you all considered the flash disabling
technique used in prefbar?  (http://prefbar.mozdev.org/)
Comment 244 Noel St. John 2005-02-18 10:02:28 PST
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.

Comment 245 Ricardo Sánchez-Sáez 2005-02-18 10:10:06 PST
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.
Comment 246 Steve Kelem 2005-02-18 12:07:29 PST
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.
Comment 247 Daniel Veditz [:dveditz] 2005-03-14 18:19:39 PST
*** Bug 254091 has been marked as a duplicate of this bug. ***
Comment 248 Daniel Veditz [:dveditz] 2005-03-14 19:21:24 PST
*** Bug 270460 has been marked as a duplicate of this bug. ***
Comment 249 Matthias Versen [:Matti] 2005-03-17 17:25:10 PST
*** Bug 286658 has been marked as a duplicate of this bug. ***
Comment 250 Matthias Versen [:Matti] 2005-05-01 15:26:26 PDT
*** Bug 292509 has been marked as a duplicate of this bug. ***
Comment 251 Charles Evans 2005-06-09 22:18:42 PDT
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.
Comment 252 Alex Bishop 2005-06-10 01:09:46 PDT
(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.
Comment 253 Jemma 2005-06-10 13:47:36 PDT
If we could right click a flash ad and block it I would be so happy.
Comment 254 paul stanton 2005-06-13 16:36:47 PDT
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)
Comment 255 Edward Lam 2005-06-13 18:53:24 PDT
(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.
Comment 256 Todd Buiten 2005-06-13 19:15:35 PDT
#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.  
      
      
Comment 257 Darin Fisher 2005-06-13 19:31:13 PDT
> ...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).
Comment 258 Noel St. John 2005-06-13 20:07:26 PDT
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. :-)
Comment 259 Ryuichi KUBUKI 2005-06-14 00:08:17 PDT
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.
Comment 260 Andraz Tori 2005-06-14 00:28:21 PDT
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.

Comment 261 Michiel van Leeuwen (email: mvl+moz@) 2005-06-14 05:19:50 PDT
(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)
Comment 262 Ricardo Sánchez-Sáez 2005-06-14 05:47:01 PDT
(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.
Comment 263 Lorenzo Colitti 2005-06-14 05:55:59 PDT
If it's just Flash that's the problem, why not just use Flashblock?

http://flashblock.mozdev.org/
Comment 264 Eyal Rozenberg 2005-06-14 08:03:14 PDT
(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.
Comment 265 jeff wilkinson 2005-06-14 08:11:26 PDT
"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.  
Comment 266 Edward Lam 2005-06-14 16:51:24 PDT
(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.
Comment 267 Warner Young 2005-06-14 17:05:34 PDT
"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.
Comment 268 Robert Rothenberg 2005-06-15 00:43:20 PDT
(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. 
Comment 269 Michiel van Leeuwen (email: mvl+moz@) 2005-06-23 06:50:51 PDT
(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.
Comment 270 Jo Hermans 2005-09-11 02:34:09 PDT
*** Bug 307860 has been marked as a duplicate of this bug. ***
Comment 271 Peter van der Woude [:Peter6] 2005-09-29 06:18:47 PDT
*** Bug 266705 has been marked as a duplicate of this bug. ***
Comment 272 Peter van der Woude [:Peter6] 2005-09-29 08:25:04 PDT
*** Bug 281827 has been marked as a duplicate of this bug. ***
Comment 273 Elmar Ludwig 2006-02-02 05:57:35 PST
*** Bug 325553 has been marked as a duplicate of this bug. ***
Comment 274 Elmar Ludwig 2006-02-02 11:30:42 PST
*** Bug 325609 has been marked as a duplicate of this bug. ***
Comment 275 Ria Klaassen (not reading all bugmail) 2006-02-14 08:00:54 PST
*** Bug 327142 has been marked as a duplicate of this bug. ***
Comment 276 Rich Gray (:rbgray) 2006-03-04 18:37:43 PST
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.
Comment 277 Chris Lawson (gone) 2006-04-02 20:17:01 PDT
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
Comment 278 Christian :Biesinger (don't email me, ping me on IRC) 2006-04-03 06:30:26 PDT
(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.
Comment 279 Chris Lawson (gone) 2006-05-07 08:58:26 PDT
(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

Comment 280 Ria Klaassen (not reading all bugmail) 2006-05-10 04:46:45 PDT
*** Bug 337413 has been marked as a duplicate of this bug. ***
Comment 281 Jackie Liu 2006-08-06 12:05:14 PDT
I would really like to see this implemented by Firefox 2.0, or earlier is even better.
Comment 282 Jackie Liu 2006-08-09 16:59:05 PDT
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.

Comment 283 Robert Rothenberg 2006-08-10 03:27:00 PDT
(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/
Comment 284 Jackie Liu 2006-08-10 13:03:52 PDT
(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.  
Comment 285 Johannes Buchner 2006-08-11 00:06:18 PDT
(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).
Comment 286 Eyal Rozenberg 2006-08-11 01:13:44 PDT
(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.
Comment 287 Jackie Liu 2006-08-11 09:36:57 PDT
(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. :)

Comment 288 Warner Young 2006-08-11 11:48:54 PDT
(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.
Comment 289 Eyal Rozenberg 2006-08-11 12:20:20 PDT
(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.
Comment 290 Jackie Liu 2006-08-11 15:50:32 PDT
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!
Comment 291 Jo Hermans 2006-09-09 12:35:13 PDT
*** Bug 351947 has been marked as a duplicate of this bug. ***
Comment 292 Ryuichi KUBUKI 2006-09-18 15:56:13 PDT
*** Bug 238388 has been marked as a duplicate of this bug. ***
Comment 293 Jesse Ruderman 2006-12-14 05:14:26 PST
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.
Comment 294 Myles 2007-01-17 05:14:07 PST
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 :)
Comment 295 Nickolay_Ponomarev 2007-01-17 05:33:01 PST
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.
Comment 296 Eyal Rozenberg 2007-01-17 07:20:32 PST
(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.
Comment 297 Edward Lam 2007-01-17 20:37:28 PST
(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!
Comment 298 Samuel Sidler (old account; do not CC) 2007-03-12 17:16:13 PDT
*** Bug 373711 has been marked as a duplicate of this bug. ***
Comment 299 Phil Ringnalda (:philor) 2007-04-02 12:06:27 PDT
*** Bug 376271 has been marked as a duplicate of this bug. ***
Comment 300 Jeremy Baron 2007-04-18 18:05:42 PDT
*** Bug 377977 has been marked as a duplicate of this bug. ***
Comment 301 Daniel Veditz [:dveditz] 2007-05-14 22:37:09 PDT
*** Bug 380701 has been marked as a duplicate of this bug. ***
Comment 302 Daniel Veditz [:dveditz] 2007-06-15 16:29:44 PDT
*** Bug 384636 has been marked as a duplicate of this bug. ***
Comment 303 Bryce Mozilla Nesbitt 2007-06-30 21:30:16 PDT
I'd be happy with "never animate stuff" as a checkbox.
Comment 304 Stephen Donner [:stephend] 2007-11-01 02:09:04 PDT
*** Bug 402003 has been marked as a duplicate of this bug. ***
Comment 305 Jeremy Baron 2007-12-04 20:22:28 PST
*** Bug 406912 has been marked as a duplicate of this bug. ***
Comment 306 Bryce Mozilla Nesbitt 2007-12-04 20:58:58 PST
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.
Comment 307 karlo 2007-12-04 22:29:16 PST
(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.

Comment 308 John David Galt 2007-12-05 20:51:34 PST
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.
Comment 309 Jacek Piskozub 2007-12-05 22:15:54 PST
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.
Comment 310 Robert Rothenberg 2007-12-06 01:57:46 PST
(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.  


Comment 311 Peter Niemayer 2008-01-07 09:43:36 PST
(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.
Comment 312 Stephen Donner [:stephend] 2008-02-04 21:05:38 PST
*** Bug 406912 has been marked as a duplicate of this bug. ***
Comment 313 Matthias Versen [:Matti] 2008-02-14 14:41:44 PST
*** Bug 417600 has been marked as a duplicate of this bug. ***
Comment 314 L Daniel 2008-02-21 08:09:24 PST
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.
Comment 315 Vincent Lefevre 2008-02-21 08:22:03 PST
(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.
Comment 316 Jacek Piskozub 2008-02-21 08:25:41 PST
Vincent is right. Therefore, please install FlashBlock from http://flashblock.mozdev.org/ and in future try to avoid spamming mozilla bugs.
Comment 317 Graham 2008-02-21 08:41:38 PST
(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.
Comment 318 Mats Palmgren (:mats) 2008-03-31 10:56:59 PDT
*** Bug 426188 has been marked as a duplicate of this bug. ***
Comment 319 Elmar Ludwig 2008-06-24 23:48:42 PDT
*** Bug 441715 has been marked as a duplicate of this bug. ***
Comment 320 Mats Palmgren (:mats) 2008-10-27 09:18:44 PDT
*** Bug 461753 has been marked as a duplicate of this bug. ***
Comment 321 mey.wer 2008-10-28 00:38:09 PDT
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.
Comment 322 Daniel Veditz [:dveditz] 2009-06-30 15:50:16 PDT
*** Bug 182763 has been marked as a duplicate of this bug. ***
Comment 323 Daniel Veditz [:dveditz] 2009-06-30 16:31:51 PDT
*** Bug 228951 has been marked as a duplicate of this bug. ***
Comment 324 Mike Beltzner [:beltzner, not reading bugmail] 2010-03-03 13:08:58 PST
This doesn't block 1.9.0.19, no.
Comment 325 Kevin Brosnan 2010-06-30 11:37:15 PDT
*** Bug 576027 has been marked as a duplicate of this bug. ***
Comment 326 Kevin Brosnan 2010-06-30 11:38:30 PDT
*** Bug 576032 has been marked as a duplicate of this bug. ***
Comment 328 Sandy Rahmat Hidayat 2010-10-01 06:17:11 PDT
Created attachment 480091 [details]
Tons of Error Console file accepted.

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
Comment 329 Ed Morley [:emorley] 2011-02-01 07:34:32 PST
Comment on attachment 130874 [details]
plugin-blocker.js (v.03)

Not a patch, unmarking patch status.
Comment 330 Ed Morley [:emorley] 2011-02-01 07:39:07 PST
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.
Comment 331 Jesse Ruderman 2011-03-02 13:27:00 PST
I think this is [parity-ie] based on
http://blogs.msdn.com/b/ie/archive/2011/02/28/activex-filtering-for-consumers.aspx
Comment 332 Matthias Versen [:Matti] 2012-05-09 10:45:33 PDT
*** Bug 753346 has been marked as a duplicate of this bug. ***
Comment 333 Anson Ng 2012-08-30 13:25:54 PDT
I guess I voted for this feature mainly for whitelist to enable Java.
Comment 334 John David Galt 2012-08-30 20:21:00 PDT
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.
Comment 335 Mason 2012-08-30 23:37:56 PDT
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
Comment 336 Thomas Schumm 2012-08-31 07:02:56 PDT
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.
Comment 337 bill 2012-11-22 05:50:18 PST
I would like to add my vote and to agree with John David Galt
Bill
http://www.cs.ucl.ac.uk/staff/W.Langdon/
Comment 338 Mason 2012-11-22 06:04:24 PST
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?
Comment 339 David Charlap 2013-01-14 14:17:26 PST
@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.
Comment 340 David Keeler [:keeler] (use needinfo?) 2013-01-14 17:15:58 PST
(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.
Comment 341 David Charlap 2013-01-14 17:41:01 PST
@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.
Comment 342 Benjamin Smedberg [:bsmedberg] 2013-02-12 12:47:39 PST
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.

Note You need to log in before you can comment on or make changes to this bug.