Closed Bug 61103 Opened 24 years ago Closed 22 years ago

Stop default plugin from launching on page load on linux (mac?)

Categories

(Core Graveyard :: Plug-ins, defect, P3)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 83754
Milestone:
mozilla1.0.1

People

(Reporter: lduperval, Assigned: peterl-bugs)

References

(
URL
)

Details

(Keywords: platform-parity)

Attachments

(1 file)

A quick fix until 83754 is done
3.23 KB, patch
Details | Diff | Splinter Review 
Whenever you get on a page that uses a plugin, you get a window that comes up
asking you if you want to download it. I want to be able to disable these
windows. For example, shockwave crashes my machine. I will *never* downloaded. I
don't want to be asked avery single time whether I want to download it or not.

Maybe something in the manner of what currently exists for exiting or entering
secure sites.
Marking NEW so someone will look at it and maybe impliment it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Add a preference to disable dialogs for loading plugins → [RFE] Add a preference to disable dialogs for loading plugins
This bug is INVALID. It's easy to do what you want. To prevent the "window that 
comes up asking you if you want to download" simply delete the Default Plugin 
(npnul32.dll, or libnulplugin.so) from the plugins folder.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Peter, if you do this, another dialog will pop up saying that you need a default 
plugin. It does right thing on Windows -- keeps a list of visited mime types in 
the registry, and pops up only if this mime type encountered for the first time.

Reopen?
reopened for peter's comments..
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Marking future and reassigning to chrisn.
Assignee: av → chrisn
Status: REOPENED → NEW
Target Milestone: --- → Future
I think this is an important feature. I'm too bothered madly by this ****
shockwave stuff.

I would suggest a fix that involves setting the Q-values of all mime types, and
if the q-value of a mime type is set to 0, it means "never download this type,
and don't bother me again with asking for it".

It is a rather broad suggestion, but it would enable people to say things like
text/html, image/jpeg, image/png;q=1, image/gif;q=0.1, application/msword,
application/x-shockwave-flash;q=0 ....
...Meaning: I would much rather have PNGs and JPEGs than GIFs, and I would never
have M$-Word and Shockwave. The latter would result in a 406 error, so the
browser would need to have a sensible treatment of the 406 error.

*** Bug 90191 has been marked as a duplicate of this bug. ***
*** Bug 87086 has been marked as a duplicate of this bug. ***
*** Bug 95583 has been marked as a duplicate of this bug. ***
There is already a preference that disables software install. I would
have assumed that unchecking this would disable the dialog which it 
doesnt. Shouldnt it? What use is it to have the dialog when software
install is disabled anyway? Or does software install not refer to
plugin install? I am puzzled.

Anyway, since some sites have a little flash plugin on practically
every page it is highly annoying to browse them 
when choosing not to install the
plugin (it crashes my mozilla both on linux x86 and sun/sparc)
BTW this is so annoying and counter-intuitive it shouldnt be an RFE but 
a normal bug.
*** Bug 91261 has been marked as a duplicate of this bug. ***
*** Bug 98933 has been marked as a duplicate of this bug. ***
*** Bug 61333 has been marked as a duplicate of this bug. ***
See bug 83754.  It seems to me that if that's implemented it will make this moot....
Depends on: 83754
*** Bug 100901 has been marked as a duplicate of this bug. ***
It seems 0.9.4 win32 doesn't suffer from this. On win32, just the puzzle piece
is shown for objects with no handler, and they have under them 'Click here to
search for a plugin' or something like that.

Why not just do that on all platforms?
Adding URL. Every page on that site pops up an error dialog about a missing
plugin. Windows doesn't popup anything until you click on the broken object
area. No longer an RFE but a pp bug. There's no need for a pref, windows Moz has
the right idea.
URL: http://www.swapoo.com/
Severity: enhancement → normal
Keywords: pp
Summary: [RFE] Add a preference to disable dialogs for loading plugins → Stop default plugin from launching on page load on linux (mac?)
Target Milestone: Future → ---
Here's another URL that shows this problem:

  <http://www.aikidojournal.com/>

I'd really like to read those pages from time to time, with 
Mozilla, but as things stand now, it's impossible. Those popups 
that nag me about the lack of a Shockwave plugin on _every 
single page load_ drive me completely bonkers. They also pop
up when I open and close my Mozilla toolbars while one of those 
pages are open! Why??!! 

This is a major bug.

Peter Lubczynski mentioned a workaround above, but of course that workaround
does not render the bug invalid, no average user will accept messing
with a system files as a way to switch off this behaviour. Also, it should
be possible on a user by user basis and hence, part of the preferences.
A simple first fix until something more fancy is cooked up would just be to 
have a "dont nag again" checkbox in that reappearing dialog window.
BTW what is the *exact* meaning of the "enable software install" checkbox?
*** Bug 69215 has been marked as a duplicate of this bug. ***
*** Bug 114272 has been marked as a duplicate of this bug. ***
*** Bug 118449 has been marked as a duplicate of this bug. ***
*** Bug 118843 has been marked as a duplicate of this bug. ***
*** Bug 121189 has been marked as a duplicate of this bug. ***
*** Bug 124595 has been marked as a duplicate of this bug. ***
The default plugin is supposed to remember the seen mimetypes and not popup
again. This may work different or not at all on some platforms in some testcase
combinations (there are many ways to trigger the default plugin).

In any case, this bug should go away with the cross-platform XBL plugin finder
in bug 83754 because I don't plan on making it auto popup. You'll have to click
first to get any popups.

The only case I am considering an auto-popup is for when the click area is too
small or hidden such as with an embedded music file to play in the background.
In this case, an auto-popup is the only way a user will be prompted for a
plugin, but it must be done only once per mime-type, with the ability to cancel.
Assignee: chrisn → peterl
Target Milestone: --- → mozilla1.0.1
Peter, will bug 83754 make Linux look how Windows has for some time? If that's
the case, sounds good. As far as auto popup on a new MIME type that's hidden,
sounds like a necessary evil. I do request a way to disable it completely
though, even if it's opening up prefs.js and adding * to
'plugin_finder.seen_mime_types'. I don't use any plugins and never plan to, and
have window.open on load disabled, so I'd like to make sure plugin finder
windows don't get through (a page could embed hundreds of plugins with random
mime types as an annoyance attack).

FWIW, my install script currently auto-deletes libnullplugin.so, and I haven't
noticed any adverse effects.
*** Bug 125638 has been marked as a duplicate of this bug. ***
*** Bug 125902 has been marked as a duplicate of this bug. ***
That patch doesn't work for some reason, everytime makeWidget is called all
static objects are reset (does it reload the nullplugin each time?)
*** Bug 127720 has been marked as a duplicate of this bug. ***
This is even more annoying than I previously had thought, which is why I'm
searching BugZilla and posting this note...

I just found out that simply changing the font size on a site will cause it to
reload enough that it will spring up the same damned "download plug-in" dialog.
 Even if one can't fix the general problem of remembering a plug-in refusal, it
certainly shouldn't be asking more than once while viewing the same page (i.e.
not even clicking a link).

e.g.  http://www.bit-tech.net/article/72/1/

Linux, BuildID 2002022821

*** Bug 134005 has been marked as a duplicate of this bug. ***
*** Bug 135882 has been marked as a duplicate of this bug. ***
Interim user-level solution, CSS:

    object, embed {display: none; }

This simply refuses to display any object or embedded content.

Thanks to bertilow, on Slashdot.

I've incorporated this in my "take back the web" userContent.css stylesheet at
http://kmself.home.netcom.com/Download/userContent.css
*** Bug 140114 has been marked as a duplicate of this bug. ***
*** Bug 142741 has been marked as a duplicate of this bug. ***
*** Bug 144611 has been marked as a duplicate of this bug. ***
*** Bug 156929 has been marked as a duplicate of this bug. ***
this will be fixed by the behavior of the new plug-in code, the new behavior
will account for this type of issue

*** This bug has been marked as a duplicate of 83754 ***
Status: NEW → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → DUPLICATE
*** Bug 159330 has been marked as a duplicate of this bug. ***
*** Bug 162094 has been marked as a duplicate of this bug. ***
*** Bug 172858 has been marked as a duplicate of this bug. ***
mass duplicate verifications . For filtering purposes, pls use keywd
"massdupverification"
Status: RESOLVED → VERIFIED
*** Bug 186686 has been marked as a duplicate of this bug. ***
*** Bug 218404 has been marked as a duplicate of this bug. ***
Attachment 69874 [details] [diff] is only for the UNIX default plugin.

Have you tried simply deleting the default plugin? 

Take a look at attachment 130874 [details] in bug 94035 which is a generic
Javascript-implemented plugin blocker.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: