56229 - useless url to download "plugin downloader plugin" (default plug-in)

Status: VERIFIED FIXED

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

Description

[Jesse Ruderman]

A page containing just <applet></applet> (bug 51040) will pop up a dialog 
asking the user to get the "plugin downloader plugin" from 
http://www.netscape.com/.  I can't find the "default plugin" or "plugin 
downloader plugin" on http://www.netscape.com/, though.  Is it even available 
from the site?

(Apparently I'm not the only one who can't find it:
http://csf.colorado.edu/archive/2000/mozilla-unix/msg01429.html)

http://lxr.mozilla.org/seamonkey/source/xpfe/components/xfer/resources/locale/en﷒0﷓

Comment 1

[ekrock's old account (dead)]

Future. The Netscape engineer this is assigned to is overburdened, and this is
not an N6 RTM blocker. Edge case. (I believe this is a DUP of another bug that
talks about using an empty APPLET tag as a form of Java sniffing, but I can't
recall the number.) 

Comment 2

[Peter Lubczynski]

The "default plugin" or "plugin downloader plugin" ships with Netscape 6 or you 
can build it from:

http://lxr.mozilla.org/seamonkey/source/modules/plugin/default/

Marking INVALID as most browser installs should come with this plugin or you can 
build it

Comment 3

[Jesse Ruderman]

I've seen this dialog mentioned several times on newsgroups and on IRC during 
the last few months.  People are still seeing it and getting confused.

Reopening.

Comment 4

[Peter Lubczynski]

I think we should just remove this and the default plugin. See bug 83754.

Comment 5

[[e-mail] (gone - use [e-mail] instead)]

This is such a useless alert dialog - at the _very_ least the URL should contain
a semblance of assistance to the user
(http://home.netscape.com/plugins/index.html comes to mind.)  But, even with
that URL, I still can't find the "Plugin Downloader Plugin".  I'd be happy to
provide a patch for this if it's just wording changes you need or to remove the
call throw this alert() window.

Comment 6

[Henrik Gemal]

please just use http://netscape.com/plugins/ or http://home.netscape.com/plugins/

Comment 7

[Winnie Lam]

Minused this bug as per ADT Triage.  83754 is the bug depended on, and it's been
nsbeta1+'d.

Comment 8

[[e-mail] (gone - use [e-mail] instead)]

Well, bug 83754 just got minused.  So, I'm going to fix this bug.

See http://bugzilla.mozilla.org/show_bug.cgi?id=83754#c55

Comment 9

[[e-mail] (gone - use [e-mail] instead)]

Attachment: Fix

Comment 10

[[e-mail] (gone - use [e-mail] instead)]

Note that the patch doesn't 'fix' the bug.  The real fix would be to find the
actual location of the "Plugin Downloader Plugin".  Since our website doesn't
support a text search (http://home.netscape.com/plugins/search_pi.html?cp=plp is
the only search page I could find), I'm assuming that this is the next best thing. 
 

Comment 11

[av (gone)]

Comment on attachment 76073 [details] [diff] [review]
Fix

r=av

Comment 12

[Henrik Gemal]

what's with the double space?
"Plugin.  Without" vs "Plugin. Without"

Comment 13

[Alec Flett]

Comment on attachment 76073 [details] [diff] [review]
Fix

ouch, that data URL just crashed me :)
(yes, talkback submitted)
sr=alecf

Comment 14

[Peter Lubczynski]

I vote to remove this dialog completely. Does it make much sense? Does anyone
care or know where to find it? Wouldn't it be just better not to show anything
if there is no default plugin? Maybe it was removed on purpose? I think almost
all builds now come with this plugin by default.

Comment 15

[[e-mail] (gone - use [e-mail] instead)]

I'm up for that, too (and could probably spin up a new patch for it).  But, you
plugin guys know your own code better than I ;-)

Comment 16

[[e-mail] (gone - use [e-mail] instead)]

http://lxr.mozilla.org/seamonkey/source/modules/plugin/base/src/nsPluginHostImpl.cpp#345

Comment 17

[[e-mail] (gone - use [e-mail] instead)]

Beth, can you make a decision here as to what we should do:

(1) Remove the call in the return value
(http://lxr.mozilla.org/seamonkey/source/modules/plugin/base/src/nsPluginHostImpl.cpp#345)
to throw up this dialog in the 1st place OR:
(2) Simply checkin the patch as stands, and leave this open to do the 1st option.

(I've since looked at the code, and can't do #1, since it's C++).

Comment 18

[rubydoo123]

I am so sorry Stephen, I did not see your last comment. We should get rid of
this dialog, it makes no sense to have it pop up.

Comment 19

[[e-mail] (gone - use [e-mail] instead)]

andre, think you could get to this for post-MachV releases like Buffy?

Comment 20

[rubydoo123]

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

Comment 21

[rubydoo123]

we will be adding an icon to the status bar, see bug 56106. setting to PL2:P1

Comment 22

[rubydoo123]

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

Comment 23

[rubydoo123]

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

Comment 24

[rubydoo123]

The dialog should be removed, adding nsbeta1+ and topembed keyword. See also bug
56106

Comment 25

[Michael Buckland]

Discussed in edt team meeting. Plussing.  We concur with comment 14 and think
the best fix is to eliminate this dialog.

Comment 26

[av (gone)]

Attachment: patch v.2

This patch removes the whole dialog.

Comment 27

[serge (gone)]

Comment on attachment 108445 [details] [diff] [review]
patch v.2

removing code is good thing to do, I like it:) r=serge

Comment 28

[Patrick C. Beard]

Comment on attachment 108445 [details] [diff] [review]
patch v.2

sr=beard

Comment 29

[Marc Byrd]

I believe #19118 is related in the following way:

(I've been out of the loop for quite a while, so I hope I'm not way off base.)  

I suggest for the gentle reader's consideration that it is desirable to 
decouple as much plugin logic as possible.  This allows decoupled innovation 
and lightens the browser.  

From this point of view, the Default Plugin is potentially a very powerful 
tool.  (I'm sorry if I'm mixing issues, but it's important background).  

Are the mimetype associations (plugins, helper apps, java?), stored in a way 
that a Default Plugin could access and manage these?  

Could it also be associated with the "about:plugins" page and take decoupled 
responsibility for rendering this, additionally providing configuration control?
Perhaps such a bigger change would have to wait.

Today, anyone could write a replacement default plugin and installer for it, 
right?  How much of the above could be done today, and how much requires 
browser-side changes?  

Comment 30

[av (gone)]

This is an interesting idea and one of its main points (decoupling the
functionality) is actually addressed in the design of the Plug-in Manager as we
see it now. Instead of using a default plugin as a plugin manager we can rather
employ the component architecture of Mozilla. Managing plugins is a complicated
task and using standard NPAPI for that will be problematic. Designing the plugin
manager as the Mozilla component means that we essentially design a set of
interfaces which would allow some privitive manipulations with plugins and which
may be or be not used to manage plugins. This plugin manager service will be
available for use from either C++ or JavaScript and it will be up to the
embedders how and to what extend to use it, whatever level of complexity of the
logic to expose to the end user as well as to decide what kind of GUI will be
appropriate.

Comment 31

[av (gone)]

Checked in to the trunk.

Comment 32

[bmartin]

Marking Verified Fixed.

The dialog no longer appears.  Instead, and .html file that contains just
<APPLET> tag will invoke a blank java box containing a red colored X in the top
left corner.