70805 - Macromedia Flash blocker

Status: VERIFIED DUPLICATE of bug 94035

(SeaMonkey :: General, enhancement)

Description

[HJ]

This is an offshoot of bug 66644 but that's more about blocking rich media
plugins. This request is all about Macromedia Flash files only! I'm getting sick
of all those Flash adds, so I wrote something to start with. I will drop some
screenshots shortly. I need your, positive I hope, feedback to make this
something for all of us.

Comment 1

[HJ]

Attachment: Screenshot 1

Comment 2

[HJ]

Attachment: Screenshot 2

Comment 3

[HJ]

Attachment: Screenshot 3

Comment 4

[HJ]

Attachment: Screenshot 4

Comment 5

[HJ]

Used pref settings in: all.js
-----------------------------
pref("network.Flash.FlashBehavior",         0); // 0-Accept All Flash files,
1-dont Accept Foreign Flash files, 2-dont load Flash.
pref("network.Flash.warnAboutFlash",        false); // if true warn me before
loading Flash files.
pref("flashblocker.enabled",                true); // if false dont show Flash
Tab in Image Manager.

BTW, who is Mozilla's/Netscape's Cookie Monster?? Akana?? I have some questions
for that person. Can someone CC him/her, thank you very much!

Comment 6

[HJ]

Attachment: Screenshot 5

Comment 7

[HJ]

Attachment: Screenshot 6

Comment 8

[HJ]

It works so far, now I need to implement an extension to the contextmenu. 

note: If you switch from Cookie Manager to Image Manager, in the original
source, then the Title does not change! Can someone confirm this bug please?

Comment 9

[HJ]

oops, no changes to the context menu.

Comment 10

[Fabian Guisset]

CC'ing [e-mail]
Marking NEW.

Comment 11

[HJ]

Attachment: changes to nsCookie.cpp and nsCookieViewer.cpp

Comment 12

[HJ]

oops, and some for nsCookieViewer.cpp. I will use cvs diff -u a next time, don't
have that on this system, and never used it before.

Comment 13

[HJ]

I changed the pref settings (from/too):
old = network.Flash.FlashBehavior  / new = network.image.FlashBehavior
old = network.Flash.warnAboutFlash / new = network.image.warnAboutFlash

Comment 14

[Stephen P. Morse]

Please hold off on doing this for a while for the following reasons:

1. Your diffs are very difficult to read and it will take too much time for me 
to figure out what it is that you are changing.  Please use cvs -u diffs.

2. I am in the process of completely restructuring the cookie module into three 
modules -- cookies, images, and permissions.  So the things that you are 
proposing to change will directly conflict with the changes that I am making.  I 
hope to have these changes ready later this week.  To monitor my progress here, 
cc yourself on bug 46783.

Comment 15

[HJ]

Wow, thanks morse, great. I will hold for now. And it's my guess that the new
implementation proberbly will be more fun to work with.

hihi, I know morse, my 'diff' looks like sh*t :)

Comment 16

[Asa Dotzler [:asa]]

updating to new owner. sorry for the spam.

Comment 17

[Boris Zbarsky [:bzbarsky]]

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

Comment 18

[Boris Zbarsky [:bzbarsky]]

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

Comment 19

[Mike Young]

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

Comment 20

[Kurt Swanson]

Is there some reason activity died off here?  I assume Morse's changes to
cookies have long since been implemented.

Flash is the one remaining major annoyance for me in using Mozilla.  I was able
to de-install the Flash plugin by hand, but every page load with Flash now pops
up a dialog asking me to install the plugin in.  (And every mouse click/scroll
in the box).

Maybe it would be best to offer a third choice to users regarding ALL plugin
installations: "no, never ask me again", in addition to "ok" and "cancel". 
Users could simply, say right-click on that insect-looking (?) icon to override
this, should they later decide they do indeed wish to induce epileptic shock via
flash animations or other annoying ****.

Comment 21

[Mirek]

I think Kurt's idea regarding handling of ALL the plugin installations(i.e.,
"no, never ask me again", "ok", and "cancel") worths filing new bug. 

Comment 22

[Niels Aufbau]

Isn't this just a special case of bug 94035?

Comment 23

[R.K.Aa.]

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

Comment 24

[Boris 'pi' Piwinger]

Yes, it is needed more and more. Flash handling like images would be great. So
you can easily block all those adds which get bigger and more annoying every new
day:-(

pi

Comment 25

[RC]

Workaround:
1. Edit > Prefs > Advanced > Software > Uncheck it
2. Rename Mozilla\Plugins\NPSWF32.dll to NPSWF32.dll.old
3. No more annoying flash.


Want to watch a flash movie?
Use the standalone player.  (flashpla.exe)

Comment 26

[Peter Lubczynski]

Wow, cool screen shots! But I really think that if we do decide to block Flash,
that this be done on a mime-type basis for ALL plugins rather than just for
"Flash". That's basically like bug 94035 and bug 11875.

However, I don't see how you actually block Flash from loading. Where's the
back-end work? A possible place to hook-in would be the same place we check for
Java being enabled:
http://lxr.mozilla.org/mozilla/source/modules/plugin/base/src/nsPluginHostImpl.cpp#3221

If you haven't copied any DLL's by hand, the suggested method to remove any
plugin, including Flash, is to use the uninstaller in the Add/Remove Programs
control panel. The current default plugin should record seen mimetypes on disk
so as not to popup again. However, this may be a moot issue because the default
plugin is going to XBL/HTML/CSS/Javascript in bug 83754.

Comment 27

[kmself]

See bug 94035 for a similar issue, with a more global solution.

The only general suggestions I'd make here are that I would prefer '035's more
general solution.  I'd also like the ability to specify the ruleset on a default
deny basis:  deny Flash (or other media content) from _all_ sites, except for
those listed.

Not sure if this is covered elsewhere, but a "flash on request only" control. 
That is, a page with Flash would *not* play or display the animation unless
specifically requested.  I'm not sure if this is a browser or player issue.

Comment 28

[Erich_J_Ritzmann]

Yes, Flash configuration would be a much anticipated preferences setting!  The
most annoying thing about some of these Flash adverts is that they disable the
user's control menu.  In addition to the lovely gecko, the next most loved
feature of Mozzie is its ability to limit the number of iterations of the
animated images!  If something similar is possible for Flash animations, that
would be ideal.  If that is too tough to do, simply a configuration that refuses
Flash mime type downloads would be better than my rm -f *.so in a fit of
frustration.

Comment 29

[Michael Lefevre]

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

Comment 30

[Boris 'pi' Piwinger]

The flash blocker should work like "block flash from this server". Is there a
reason this bug is limited to Windows?

pi

Comment 31

[Olivier Crête]

Should be on all platforms which have the plugin... Linux and MacOS should be
included... Also, the bug from which that one has spawned has been closed in
favor of bug 19118, which is in my opinion not the same at all... Anyways, it
would be nice to have a flash blocker just like the image blocker as banners go
more and more towards flash

Comment 32

[John Villalovos]

Is there anything going on with this bug?  It would be great to have this
functionality because it seems like more and more ads are using flash. 
Currently there is no way to block this.

I'm voting for this bug :)

Comment 33

[Gábor Lipták]

for Flash blocking you could use

http://www.privoxy.org/

Comment 34

[Boris Zbarsky [:bzbarsky]]

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

Comment 35

[Alfonso Martinez]

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

Comment 36

[Adam Hauner]

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

Comment 37

[Manko]

I have opened bug 147866 as more generalized issue, please vote for it ;)

Comment 38

[R.K.Aa.]

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

Comment 39

[Alex Hosking]

Do you want to get rid of all flash or just the adds
Because if this is just the adds this is the job of banner blinds (Witch I dont
like)

Comment 40

[Geir Hedemark]

Well, if by "you" you actually mean me, I think Flash mostly is a
pain-in-the-ass attention grabber which I would rather do without. 99.5% of the
flash thingies out there are garbage, and add no content to the site who has them.

No, this is not an ad issue, although they are part of the same problem.

Comment 41

[Daniel Wang]

I have just filed a generalized version of this bug. see bug# 152245

Comment 42

[Daniel Wang]

I have just filed a generalized version of this bug. see bug# 152245

Comment 43

[Manko]

I can suggest one interesting solution if you don't want see ads but want see
flash navigations or presentations.

What about implementing feature to turn off autostart for plugins in
Preferences? I think, this will be good palliative, easier for realization.

Comment 44

[jerry asher]

What is it that enables Mozilla to play flash in the first place?  Is it solely
code within Mozilla, or does Mozilla call (or callback) various pieces of flash
code?

If the latter, then one alternative is to approach Macromedia, show them Mozilla
image blocking, and then ask them to make flash much friendlier, perhaps by
having them examine the user preferences regarding autostart.  When asked to do
the right thing on their own when the alternative is to have Mozilla developers
develop  something potentially far worse for Macromedia, then it is
likely/possible that Macromedia will see this as an opportunity for them to
create the best outcome for everyone.

Comment 45

[Manko]

I think, Macromedia isn't interested (or interested negatively) for this issue.
Flash is proprietary standard, and Flash ads are Macromedia's daily bread.

I hope for SVG to kill Flash, but we're living in real world. Flash is just one
of many plugins, and all that is being discussed there must be implenented in
Mozilla common plugins module, not in Flash. Flexible policy for all embedded
content including external Java applets, javascripts, iframes etc. is, IMHO,
strongly needed (see bug 147866). But it's complicated issue, I don’t suppose it
to be implemented in near future.

I think, turning off autorunning of plugins could be easy-to-implement feature
which can relieve all of us.

Comment 46

[av (gone)]

Plugins as opposed to animated gifs e.g., are executables. Animation with gifs
is up to our presentation, while plugin appearance is up to the plugin. Once
loaded and called, plugins take over and can do whatever they want. There is no
way to disable autorun in general case. AUTOSTART attribute for the embed tag is
just one of possible attributes. Even if we intercept it and override with FALSE
this will only be a solution for those plugins that rely upon it. In other
words, there is no such thing as autorun for plugins, plugin functions like PLAY
and STOP are not under Mozilla control.

Comment 47

[jerry asher]

<i>
In other
words, there is no such thing as autorun for plugins, plugin functions like PLAY
and STOP are not under Mozilla control.
</i>

Interesting, being generous to Macromedia, I believe we might be able to send
Macromedia a letter stating that, 

 o  there's a bug in Mozilla about disabling Flash
 o  it's relatively simple for Mozilla developers to
    allow users to disable ALL flash similar to 
    how users of Mozilla can block images, pop ups, and pop unders
 o  or Macromedia can do the right thing and build in some user
    courtesy preferences on their own.

I wonder how such a letter might be received, esp. if cc'd as well to Jakob
Nielsen who evidently no longer believes that FLASH is completely worthless. 
I'd wonder if such a letter would receive Nielsen's support (or else be seen as an
embarrassment to a hypocritical Nielsen who was least seen taking some
Macromedia consulting money.)

Anyway, I think it would be an interesting and fun exercise, and I do think it's
a potential win-win for all.

Comment 48

[Brian Vetter]

There sure is a lot of activity with these types of enhancement requests. There
are some very similar bugs, not quite dupes, logged for this very same type of
enhancement. For instance, the info in bug #94035 is very appropos for solving
the problem here (and a solution for one would most likely cover both quite nicely).

The implementation details are little bit messy. The fact is Flash, along with
some other media types, is inserted into the page via the object tag. To
actually scan for flash ads, you have to change the generic code for handling
the object tag. In addition, the actual url of the server is provided as a
parameter to the plugin/object. In essence, you have to parse the object tag and
inhibit the placement of the control based upon parameters passed to the tag.

To complicate this some more, the ad may be served via an embed tag instead of
the object tag. Same drill, but the URLs tend to be nastier and again, the meat
is in parameters to the embed. In both cases, there is an identity mechanism for
the plugin - a classid for object tags and a mime-type for embed tags. To pull
this off, you need some kind of filter mechanism for handling the parsing and
loading of object and embed tags - it just gets too complicated to handle all of
the cases.

If that is not enough, you have to ask yourself why block the flash images. Is
it the distraction and intrusiveness of the interface, or do you want to avoid
the media outlet tracking you (ala doubleclick)? In the latter case, you can't
just block images and object/embed tags. You also must block frames and iframes.
A common layout trick is to put ads into an iframe instead of just referring to
it directly. As for blocking the images from the UI, you can still handle that
with the various img, embed, and object tag blocking functions. But they can
still track you during the loading of the iframe.

Pegging images, objects, and plugins to a specific host computer is sometimes
difficult unless you want to ferret out all of the good content with the bad.
Bug #78104 suggest tying the site to a pattern. This might be too hard for a
naive user, but then advanced blocking configuration probably would. 

And finally, I've seen a few mentions in the privacy area that, ideally, there
would be client side blocking of any interaction with a given server. Combined
with the pattern matching of 78104, you could not only block images and flash
movies, but any kind of obnoxious content - in fact everything from a given
server is condemned. By doing so, you wouldn't have to worry about attempts to
load headers (and not content) be able to track your habits.

Comment 49

[jerry asher]

<i>
There sure is a lot of activity with these types of enhancement requests.
</i>
It would be interesting to know why folks use Mozilla and not I.E.  I myself
came back to Mozilla for the image blocking/pop up defeating features touted in
a  release note mentioned on /..   Privacy, Lack of Popups, Ease of Use (tabbed
browsing) are the benefits of Mozilla I always use when prosletyzing for
Mozilla. (Spamming my friends about new releases.)

I am very glad 1.0 has been released.  If as I think is true, that a significant
chunk of folks use Mozilla for the benefits I mention, esepecially when compared
to the privacy defeating, easy tracking, terrible UI of IE, than it might be
wise for the Mozilla project to beef up such consumer oriented features.

"The browser war" might then shape up as IE, written to provide benefits to
corporations vs. Mozilla, written to help and protect the consumer.

Comment 50

[Manko]

Does Macromedia plugin support LiveConnect? Maybe, this is a way to stop Flash
animation?

And, in any case, to add more power to user and allow to enable context menu
always, we can stop support these attributes:
menu="false" and swLiveConnect="false" in <embed>
<param name="menu" value="false"> and
<param name="swLiveConnect" value="false"> in <object>

Then user will can stop animation manually even if webmaster doesn't want it ;)

I hope, this is very simple and near to realize.

Comment 51

[R.K.Aa.]

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

Comment 52

[Matthew T (active 1999-2002)]

Predictably, there is far, far too much user interface here for controlling one
particular plug-in. It's totally out of line with the importance of the feature.

*** This bug has been marked as a duplicate of 94035 ***

Comment 53

[Adam Hauner]

Voters, move your votes to bug 94035.

Comment 54

[[e-mail]]

I think it is not very constructive to dupe a bug that has got so much
input and activity against a bug that is not really a dupe, since it
wants something more general, and hence more complicated, needing more
effort and having less likeliness of getting solved.
This is a very frequently asked for feature and it might be a perfectly
valid aproach to solve the special case now and throw it away if somebody
really comes up with the wonderful general case solution.
Whether there is too much UI for this or not is something that should be 
discussed by UI experts but should not be a criteria for whether this 
bug gets closed as a dup or not. 

Comment 55

[Daniel Wang]

#48 says it all. The issue is much more complicated then just blocking
a particular plug-in. I'm for the dupe. If there's any general issue
raised here but you think aren't addressed by bug 94035 and other bugs,
please file an offshoot bug.

Comment 56

[Wesha]

Agreed. One "general" fix is much better than ten problem-specific ones, at
least from the maintainability POV. I vote for the dupe.

Comment 57

[Jesse Ruderman]

The "zap embeds" bookmarklet removes flash, java, and iframes from a single page.  
http://www.squarefree.com/bookmarklets/zap.html

Comment 58

[Matthew T (active 1999-2002)]

It doesn't make any difference to the resolution of this bug, but for the smooth
running of Bugzilla I think it's worth making one point.

> I think it is not very constructive to dupe a bug that has got so much
> input and activity against a bug

In general, the more `input and activity' a bug report has, the more useless it
is. If you're speaking vaguely of `input and activity' it's unlikely that any of
that activity consists of patches and reviews, and it becomes harder to find and
read the comments which *are* patches and reviews. Indeed, of the 57 comments in
this bug report prior to the one I'm writing now, 17 of them (by my subjective
count) are practically useless comments of the `yes, this would be cool!' or `I
don't know how to fix this bug but I'll mumble something vaguely relevant
anyway' form, and only two are patches or reviews. That's completely backward.

So please, before commenting in any bug report, think: Will this comment really
make it easier for someone (not `encourage someone', but `make it easier for
someone') to produce a patch which gets checked in? If not, don't post it.

Comment 59

[Wesha]

v.

Comment 60

[Jamie Nicolson]

Hey, would anyone be interested in bug 169330: "Flash click-to-view" as a
solution? The idea is that Flash animations wouldn't run until you click on them
to start them. In my experience, I can always tell just by looking at the page
whether I want to run the Flash animations on that page. I think blocking flash
by site is too bulky and complicated a solution. I'd rather do it manually.