Replace C++ version of default (null) plugin with XBL one

RESOLVED FIXED in Future

Status

()

P1
enhancement
RESOLVED FIXED
18 years ago
5 years ago

People

(Reporter: dr, Assigned: peterl-bugs)

Tracking

(5 keywords)

Trunk
Future
arch, embed, helpwanted, memory-footprint, platform-parity
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [driver:blizzard][PL2:P1])

Attachments

(1 attachment, 5 obsolete attachments)

(Reporter)

Description

18 years ago
Having a default plugin which conforms to either our new our legacy plugin APIs
gives us some technical challenges: primarily, since plugins aren't able to take
advantage of Mozilla's XP features, simple necessary changes in the null plugin
are difficult to make.

The example motivating this bug is bug 73129. We need to modify how the default
plugin poses the "get plugin" dialog to behave correctly in the embedded case.
This is currently difficult because *each* platform-specific implementation of
the default plugin has a different (and in some cases, hackish) way of posing
this dialog.

The way I'd like to go about solving this architectural problem is removing the
default plugin entirely. It seems to me that we can very easily re-implement the
default plugin's functionality as follows:

  - Create a simple XUL file (probably something like "chrome://noplugin.xul")
    which contains:

    1. A blank page with the jigsaw-puzzle icon in the center, and text
       saying "click here to download plugin" (this should look exactly like
       what we currently have).
    2. Logic (in script) for handling the user's click, posing the dialog
       to download the plugin, or whatever else we'd like to happen.

    This is a Good Thing for the same reason XUL/XBL and all that are Good
    Things. For comparison (if this confuses you), imagine having to code
    platform-specific versions of the "about:" page...

  - Create a new embedding-friendly API to pose the dialog we want, used by
    the simple code mentioned above. (This shall be the purvue of bug 73129,
    and won't be mentioned further here).

  - In the code which looks up plugins to handle a particular mime-type, if
    we do not find any handler for the given mime-type, we create an IFRAME
    in the webpage where the plugin would have been, and load the XUL page
    mentioned above in it.

The interesting part here, which Peter Lubczynski mentioned, is that there's
already code similar to this living in gecko, to handle the unusual case where
we happen to be missing not only the "correct" plugin but also the default
plugin. We'll probably be able to simply modify this code to suit our needs as
described. At that point, the default plugin can just plain go away.

So everything seems beautiful and rosy. But there's just one question remaining:
Is it okay to remove the default plugin, or is there some reason I'm missing for
why we still have it around?

I'm looking for input from av or bnesse as the recommended domain experts here,
since everybody else seems to think this is a Good and Right Thing to do. Please
let me know if this is copacetic. Thanks!
(Reporter)

Updated

18 years ago
Status: NEW → ASSIGNED
Keywords: arch, embed, footprint, mozilla0.9.2, pp
Priority: -- → P1
Target Milestone: --- → mozilla0.9.2
(Reporter)

Updated

18 years ago
Blocks: 73129

Comment 1

18 years ago
I like this idea of removing the null plugin, but as long as most of the 
functionality is not lost but moved to plugin internals. I don't even 
think the W3C says anything about a "default plugin" and it should cut footprint 
so this is probably a good idea. Besides, XUL is cool, localaizable, and 
easily overridable. Going through the Win32 source, a few issues come to mind:

1) On Win32, we're using the Windows registry to "remember" MIME types we've 
seen. It should not be hard to use the Mozilla Registry or prefs instead. 
Issues???

2) Need to ensure a clean approach to multiple plugins on a page. Forgot how we 
handle this now but we probably only want to prompt once for each seen MIME type 
on a page just in case there are multiple tags of the same type. #1 may take 
care of this but I recall there being a bug on this before. Also check for 
nested plugin tags cases, see #6

3) npnul32.dll source reveals a special case URL for Java???? Use a pref maybe? 
Dunno...

4) Source shows special case for being off-line????

5) There is also a "SmartUpdate" feature that looks like it's been turned off. 
It would be good to coordinate with Rafael's team on this. I've seen a new 
experimental server-side delivered about:plugin "manager" that looks interesting 
and cool. Perhaps integrate #3, #7, #8. Plus, some of our embedding vendors 
wanted a cleaner user experience for downloading plugins that "SmartUpdate" 
could probably once again provide.

6) Double check with the W3C spec as to rendering alernate content if a plugin 
can not be found or installed. With all the code inside plugins, we can probably 
handle this case better than we do now.

7) Don't forget about the attributes: pluginspage, codebase, pluginurl, classid 
(???), SRC, and HIDDEN. Some are old school Nav and others are W3C. 

8) Don't forget to issue the refresh command: 
javascript:navigator.plugins.refresh(true) after "install" Issues here????

9) Remember NOT to include the default plugin in plugin folder scan on client 
machines. We don't want to accidentally pick up an old "default plugin" on 
accident when sweeping the 4.x folder or in an installation over an exsisting 
Mozilla/Netscape 6. However, it would still be nice to leave in the ability for 
a 3d party wildcard (*) plugin.

cc:ing mkapley for OS/2 impact.

Well, I guess the default plugin does more than I thought and removing it would 
require taking care of at least those issues. But I think it'll also fix a few 
other bugs and make for a better user experience in both "Mozilla/Netscape" and 
embedded products. I really like the idea and am willing to help out but am also 
interested if Andrei or Brian have any other issues?

Comment 2

18 years ago
We didn't even bother shipping the npnulos2 plugin on OS/2 - we tell people to 
get it from 4.61 if they need it.

I would love to see this thing go away.

One less piece of platform specific code.

Comment 3

18 years ago
I believe Peter's list touched on all of the potential issues, but let me think 
as I write...

When a plug-in is missing, the current "Default" plug-in jumps in, draws a 
missing plug-in icon in place of the missing content, and asks the user if they 
want to get it.

If the user wants the plugin, they are directed either to the default Netscape 
plug-ins page, or to a download site as specified by the optional attributes.

If the user doesn't want the plug-in, the "Default" plug-in notes the mimetype 
info about the plugin and moves on.

So, as Peter noted, we definitely need a way to "remember" the fact that the user 
has already been notified of the missing plugin already. If they didn't want it 
the first time, they don't want to be told they are missing it again and again. 
Due to the loss of write access to the resource fork, the Mac version now retains 
this info in a local data file (I forget the name.)

The advantage to the current functionality is that the plugin allows the page to 
layout properly without the missing plugins. Redirecting the user to a "A blank 
page with the jigsaw-puzzle icon in the center" will not be acceptable because it 
eliminates the ability to choose not to get the plugin. Keep in mind that server 
or connection related issues might also keep the user from being able to download 
the plug-in, even if they do want it.

Some of the special cases Peter mentioned:

There is a special case for Java. Requests for the Java plugin on Windows & Linux 
are directed to a location other than the standard plug-in download page. 
Shouldn't be any specific issues related to this.

If the user if offline, the plugin:
1) doesn't bother trying to fetch the plug-in.
2) doesn't retain the mimetype info, thus making it so that the next time the 
user comes across that mimetype they get prompted to download it.

There was a tie in to the Communicator "Smart Update" feature. I'm uncertain of 
the status of this option.

I'm guessing that to make this work correctly, some changes to the plug-in code 
will be needed so that the plug-in code can determine that the plug-in is not 
available and draw the "broken icon" instead of the plug-in content.

Comment 4

18 years ago
Right, and I think there is also the case of alternate content, the stuff that 
gets displayed when we can't render the OBJECT but before the puzzle piece. For 
example, see: [Bug 46569] OBJECT tag does not work for plugins if classid 
attribute is specified

I don't think we currently do this correctly according to W3C spec on OBJECT 
tag, but I haven't tested it extensivly.

Question: should we throw up the "plugin finder" logic if the first OBJECT tag 
can't be rendered or the last nested OBJECT tag can't be rendered. I'm not sure 
which way it is now. To add yet more complexity to this issue, there is also the 
case where we get a SRC= but no MIME type (like a CGI delivered stream) until 
the server hands one back. But, by that time, we're halfway in the middle of 
everything, with an open stream. I think the current code does this fine for a 
simple situation, but nested OBJECT tags make me queasy.
(Reporter)

Comment 5

18 years ago
Reponses to some comments:

Peter Lubczynski:

> 1) On Win32, we're using the Windows registry to "remember" MIME types we've
> seen. It should not be hard to use the Mozilla Registry or prefs instead.
> Issues???

No issues I can think of. The more platform-specific code I can tear out, the
happier I'll be.

> 3) npnul32.dll source reveals a special case URL for Java???? Use a pref
> maybe? Dunno...

Don't think there's anything too special we have to do here. Since all the logic
of where to redirect users to will be handled in <script> in the XUL frame, that
special case can just live in that logic.

> 4) Source shows special case for being off-line????

Same thing here...

> 5) There is also a "SmartUpdate" feature that looks like it's been turned off.
> It would be good to coordinate with Rafael's team on this. I've seen a new
> experimental server-side delivered about:plugin "manager" that looks
> interesting and cool. Perhaps integrate #3, #7, #8. Plus, some of our
> embedding vendors wanted a cleaner user experience for downloading plugins
> that "SmartUpdate" could probably once again provide.

Hmm. I'm certainly not ready to tackle something of that magnitude alone, and if
I were to coordinate with Rafael's team on something this big, I don't think it
would make it into 0.9.2. I'll see what's up with this, though...

> 6) Double check with the W3C spec as to rendering alernate content if a plugin
> can not be found or installed. With all the code inside plugins, we can
> probably handle this case better than we do now.

Ok, I'll double-check. I was assuming just showing what we show now would be
"plenty correct" but I'll see if there's anything special that we aren't doing.

> 9) Remember NOT to include the default plugin in plugin folder scan on client
> machines.

Oooh. Is there a way to send a "who are you?" query to a plugin?

> I really like the idea and am willing to help out but am also interested if
> Andrei or Brian have any other issues?

All your help would be *much* appreciated :)

I received email from av, by the way:

> Doing `smart` things seems to be the only thing which justifies the whole idea
> of having the default plugin. Otherwise, I like the idea of a "XUL in an
> iframe".
> 
> av

So it seems that answers that question :) And I suppose if the "smart things" we
need to do aren't easily doable in js from <script>, we could just as easily
slap together a C++ impl and use it through XPConnect.

Brian Nesse:

Thanks for the step-by-step info -- that gives me a much better idea of what to
expect. Just one clarification:

> The advantage to the current functionality is that the plugin allows the page
> to layout properly without the missing plugins. Redirecting the user to a "A
> blank page with the jigsaw-puzzle icon in the center" will not be acceptable.

I think you misunderstood the use of the XUL here -- we're not redirecting the
user to this page, we're displaying it in an IFRAME where the plugin would be.
That's our new, sexy way of showing the "missing plugin" icon (rather than
having platform-specific drawing code to draw the same icon).

Thanks again, and keep the comments coming. My first priority is to determine
whether this can make it into 0.9.2, so right now I'd like to either:

  - Formulate a game-plan here which would permit an 0.9.2 landing, or
  - Decide not to do this for 0.9.2 (which would imply that I'd punt on 73129)
    and come up with a strategy for 0.9.3.

Of course, given that this is, at least nominally, for embedding, which has a
strict deadline, I'd suspect we should try hardest to work out an 0.9.2
solution. Phil probably has some input on this.

Ideas?

Comment 6

18 years ago
Adding George Drapeau.

Comment 7

18 years ago
As to displaying alternate content, I think we currently have a logic in the 
code not to invoke the default plugin in case of the object tag but rather to 
render the alt content. The default plugin takes over only on the embed tag 
(which is not supposed to have alt content at all as far as I remember the 
spec). We probably don't see this behaviour in real life much just because the 
object tag is usually altcontented with the embed tag.

As to leaving wild card (*) possibility. We should probably look for such a 
plugin and give it a preference if one exists. Not for our 4.x sweep though. 
Peter, do you agree? 

Comment 8

18 years ago
Andrei, yes I agree. Things like the spy plugin register for * MIME types.

> Of course, given that this is, at least nominally, for embedding, which has a
> strict deadline, I'd suspect we should try hardest to work out an 0.9.2
> solution. Phil probably has some input on this.

If you can do this for mozilla0.9.2, more power to you!

> 9) Remember NOT to include the default plugin in plugin folder scan on client
> machines.

>Oooh. Is there a way to send a "who are you?" query to a plugin?

Andrei or I can probably help you with that. I think there is already some 
special code for identifying the default plugin, so we just may need to hack 
that (hopefully). We could also query the plugin for it's "Description" or 
mime type or we can filter it out by filename in the directory scan.

Since the orriginal default plugin used Javascript anyway to do it's "smart" 
things, it'll probably be easier to do this in XUL than in C++ anyway. Just as 
long as your XUL page's javascript can get to the attributes of the right tag.

A new bugscape bug was opened by Rafael on a new server-side plugin manager that 
looks like it'll make it in for mozilla0.9.2 or soon thereafter. The reason you 
may want to coordinate is for the "finder" feature of the default plugin where 
it redirects to Netcenter. IMO, it doesn't do this very cleanly now, but if you 
are re-writing that code perhaps you can make it right the first time. It'll 
probably just be all javascript and perhaps the URL's can be set in prefs or 
something.

Comment 9

18 years ago
By the way, has everybody overlooked the case of full-page plugin? It will 
probably be simpler as we don't need to insert iframe. Is this correct?

Comment 10

18 years ago
Full-page plugins don't invoke the null plugin.

They go down the helper path.

Comment 11

18 years ago
I remember there was a bug on not invoking the default plugin in full-page mode. 
I think we don't need to do anything here. The content type in full-page case is 
solely determined by file extension, so this is already a degree of guessing 
from our side, and yes, it goes to the helper app in case there is no plugin 
installed.

Comment 12

18 years ago
I agree, full-page plugins go the route of a helper app and no default plugin 
should interfear.

Comment 13

18 years ago
Adding Ed Burns, Igor Kushnirskiy, who both have experience with Mozilla
Plug-Ins module.  I'll make my own comments later.

Comment 14

18 years ago
Okay, here are my comments:

I think Brian and Peter have covered all the basic issues.  As long as the logic
can be implemented in an XP way, I'm --- wait for it --- all good with doing it
with XUL-n-such.
(Reporter)

Comment 15

18 years ago
Ok, after speaking with karnaze, this seems more like a post-0.9.2 candidate.
Triaging to 0.9.3. I'm trying to figure out, over email with aruner, how this
affects bug 73129.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
(Reporter)

Updated

18 years ago
Blocks: 58291

Updated

18 years ago
Blocks: 62513

Comment 16

18 years ago
add to cc list
(Reporter)

Comment 17

18 years ago
*** Bug 62513 has been marked as a duplicate of this bug. ***

Updated

18 years ago
Blocks: 86645
(Reporter)

Updated

18 years ago
Blocks: 56231
(Reporter)

Updated

18 years ago
Priority: P1 → P3
(Reporter)

Comment 18

17 years ago
no.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX

Comment 19

17 years ago
Any thougths?
(Reporter)

Comment 20

17 years ago
[spam] working on toolkit: plugins bugs => plugins team.
Assignee: dr → peterlubczynski
Status: RESOLVED → NEW
Target Milestone: mozilla0.9.3 → ---

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → Future

Updated

17 years ago
Blocks: 92322

Comment 21

17 years ago
Assigned bugs shouldn't have a resolution, should this be assigned or resolved
wontfix?

Updated

17 years ago
Resolution: WONTFIX → ---

Updated

17 years ago
Blocks: 56229

Updated

17 years ago
Keywords: helpwanted
We should also be very careful to not use any default-plugin if an unrecognized 
<object> has children. In that case we should always render those children 
instead of the <object> since the author is much more likly to know what an 
appropriate errormessage is then a null-plugin...

Also, there is the argument that that is what the specs say :)

Comment 23

17 years ago
This fact is addressed in the default plugin instantiation code: before doing
|SetUpDefaultPluginInstance()| we check if this is an object tag and if so just
return with error code which in turn triggers rendering the object tag content.
I think the SetUpDefaultPluginInstance function body can be used as a place for
writing the planned new iframe content generation code, and thus we should be safe.

Updated

17 years ago
Target Milestone: Future → mozilla0.9.6

Updated

17 years ago
Blocks: 44711

Updated

17 years ago
Blocks: 98976

Comment 24

17 years ago
------- Additional Comments From timeless@mac.com 2001-06-25 14:42 -------

ok, so bug 55261 magically resurfaced, it had
attachment 16330 [details] chrome://navigator/content/nullpluginDialog.xul
attachment 16331 [details] chrome://navigator/content/nullpluginDialog.js
attachment 16332 [details] chrome://navigator/locale/nullpluginDialog.dtd
attachment 16333 [details] [diff] [review] Patch [doesn't work, probably a security violation]

Updated

17 years ago
Blocks: 95157

Updated

17 years ago
Blocks: 57455

Comment 25

17 years ago
*** Bug 101833 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Blocks: 54147

Updated

17 years ago
Blocks: 69215

Comment 26

17 years ago
0.9.6 targeted and no talk in a while. Any work done here? Null plugin is
causing me much grief.

> When a plug-in is missing, the current "Default" plug-in jumps in, draws a
> missing plug-in icon in place of the missing content, and asks the user if they
> want to get it.

Is the dialog really nessicary in the new implementation? It's rather annoying
currently, especially since on Linux MIME types you've said no to aren't
remembered. I think the "click here to find a plugin" on the object is alot
nicer, not throwing excessive dialogs at the user.

Comment 27

17 years ago
No a dialog isn't necessary. I found this out while critiquing the Xlib null
plugin impl.  It's actually totally useless. (my revision of that plugin
downloader made clicking the plugin placeholder go directly to download).

This should be doable w/ a rather small amount of xbl, why don't you try?

basically the plugin needs to force itself to take up enough space to show:
plugin missing icon, plugin type, alternate content.
On mouseover of the icon it should probably indicate the plugin data url, and
that clicking the widget will attempt to retrieve a plugin handler.

Updated

17 years ago
Target Milestone: mozilla0.9.6 → mozilla0.9.7

Updated

17 years ago
Blocks: 108605

Updated

17 years ago
Keywords: helpwanted
Summary: Remove default (null) plugin. → Replace C++ version of default (null) plugin with XBL one

Comment 28

17 years ago
Created attachment 57667 [details]
pluginfinder.zip: first try at implementing the default plugin in XBL

The above zip file contains a working first try of converting the C++ default
plugin to XBL. This is still a work in progress and here are a few things left
to do:
1) Hookup C++ side to replace content. Problem here is that the replacement
destroys my object frame synchronously and we have a crash later in reflow. The
replacement either needs to happen asynchronously or I need to prevent my frame
from being destroyed.
2) Use a DTD for localization. Do I need to convert my HTML to XUL?
3) Hook up as part of chrome or resources. Where should this live?
4) Special case Java???? The C++ ones do this but I think the plugin finder on
Netscape.com should be smart enough to do the redirection instead of coding
special logic into the browser.

Comment 29

17 years ago
Created attachment 58027 [details] [diff] [review]
updated, working, fix, in nice patch form

This still needs a little cleanup plus I need to figure out how to localize it.
However, it should work as long as you remove the current default plugin. 

Can someone with more XBL experience give me some tips? Thanks!
Attachment #57667 - Attachment is obsolete: true

Comment 30

17 years ago
Created attachment 58028 [details]
plugin-puzzle.gif
(Reporter)

Comment 31

17 years ago
Glad to see you guys are finally getting to this.

To localize something in XML, for example:

<handler event="click">
  alert("foopy");
</handler>

you replace the text to be localized with an entity reference:

<hander event="click">
  alert("&my.foopy;");
</handler>

and define that entity in a DTD (there's probably a suitable place to put it in
global resources or something... I'm sure jag would know.):

<!ENTITY my.foopy "foopy">

I've never done this, but I think it ought to work.

Comment 32

17 years ago
Created attachment 58397 [details] [diff] [review]
localized patch

This still needs work. I can't seem to get my replaced element to stay inline.
It's always turing into a block despite I "extend" from html:span, directly
apply an inline style in my XBL rule, and even tell my table to be inline.
Also, if I "extend" from chrome://global/content/bindings/general.xml#basetext
like some of the other bindings, I hang in endless reflows. Any ideas?
Attachment #58027 - Attachment is obsolete: true

Comment 33

17 years ago
*** Bug 73129 has been marked as a duplicate of this bug. ***

Comment 34

17 years ago
Created attachment 59702 [details] [diff] [review]
new patch

This patch addresses all my concerns:

1) The plugin will now always be inline because I only used SPAN tags and CSS
to make it look like the exsisting one.
2) There is a DTD for localization
3) Added some helpful information to the prompt message, status bar, and
tooltip
4) Removed annonying auto-popup feature
5) No more special case redirect URL for Java
6) Moved XBL style rule to quirk.css
7) Moved gif/css/xml/dtd to chrome:// space

Please comment/review?
Attachment #58397 - Attachment is obsolete: true
+      nsString value; value.AssignWithConversion("xbl");

Just drop this temporary completely.  Instead of passing |value| to
PostAttributeChange, pass in NS_ConvertUTF8toUCS2("xbl")

Better yet, change PostAttributeChange to take an nsAString instead of nsString
and then pass in NS_LITERAL_STRING("xbl").

There seem to be a few new files with no newlines at the end in this patch...
(Reporter)

Comment 36

17 years ago
looks pretty good to me, but you /really/ ought to ask jag for a real thorough r=.

Updated

17 years ago
Blocks: 85269

Comment 37

17 years ago
+      // set the default redirect URL
+      if (mType)
+        mRedirURL = "http://cgi.netscape.com/cgi-bin/plug-in_finder.cgi?" + 
mType;
+      else  // fallback case
+        mRedirURL = "http://www.netscape.com/plugins/";
+
+      // the author of our plugin tag may have wanted to redirect the user to 
get 
+      // the plugin. We may either have (in order or use):
+      // a) PLUGINURL: an URL pointing to an XPI (or other type of installer) 
package
+      // b) PLUGINPAGE: an URL pointing to something else like a web page
+      // c) neither and so we redirect to the plugin finder service on 
Netscape.com
+      //    passing in the mime-type
+      
+      var redirPage = this.getAttribute('pluginurl');
+      if (!redirPage)
+        redirPage = this.getAttribute('pluginspage');
+      if (redirPage)
+        mRedirURL = redirPage;
mRedirURL  = this.getAttribute('pluginurl')
          || this.getAttribute('pluginspage')
|| (mType) ? "http://cgi.netscape.com/cgi-bin/plug-in_finder.cgi?" + mType 
           : "http://www.netscape.com/plugins/";

+      // ask the user if the want to get the plugin and also provide some 
helpful information
one of these 'the's is wrong.

+      var isOKToGetPlugin = 0;
+      if (1 == mReadyToInstall) {  // only ask user once
+        isOKToGetPlugin = confirm("&confirmGetPluginMsg;"); // do the asking
i suggested that we not provide a dialog and instead make the puzzle piece a 
normal image link the first time.  IMO it's cleaner to do this (it would allow 
users to right click the puzzle piece and open in new window/tab, copy link 
location, just open, ...), the piece would appear like a normal link...  Alerts 
are annoying...  This isn't a deal breaker, I could file an enhancement request 
after this lands.  Changing the behavior does simplify the later code...
+        if (isOKToGetPlugin) {
+          var win = window.open(mRedirURL);
+          mReadyToInstall = 2;  // so status bar only changes AFTER confim 
dialog goes away
+        }
+      }

you have a few of these:
\ No newline at end of file
you should fix them :)

one of the xml files is listed as MPL|GPL, please fix to MPL|LGPL|GPL.

Comment 38

17 years ago
Timeless asked me to comment on the use of an alert ...

It is my belief that over the course of development of any software which aims
for maximum usability, the number of alerts posed by the software should
approach zero. The unknown embedded data problem is an easy example of how an
alert can be made unnecessary. I suggest the UI consist of two items:
(1) the iframe thing previously discussed (I think this should look like a
    bevel button {background-color: ButtonFace; color: ButtonText; border: 1px
    outset ButtonFace;} of whatever size the page specified, featuring the
    embedded data icon and the text `Get the plug-in');
(2) the same icon (but smaller) in the status bar, with accompanying text
    `[%] Done, but some objects have no plug-in' (analagous to the `/!\ Done,
    but with script errors' we should show if something goes bad with JS on the
    page), which can also be clicked to do the find-the-plug-in thing.

In one fell swoop, this would solve the following problems:
*   the alert itself would go away;
*   you wouldn't have to remember special state so as not to put up the alert
    repeatedly when navigating through session history;
*   OBJECTs containing alternates of known type would still be accessible,
    since (2) would still be available to click (just because I can view the
    alternate .png doesn't mean I never want to learn how to view the .mov);
*   stuff like background sounds which had no (obvious) clickable area would
    become accessible, since (2) would still be available to click.

A final note: Mac Mozilla, like all Mac browsers, takes its plug-ins from the
`Internet Plug-Ins' folder in the `System Folder', and this folder contains a
`Default Plugin' used by Netscape 6.2 and earlier Mozilla milestones. It would
be nice if the fix for this bug would work for Mac Mozilla, without seeking and
destroying the null plug-in from the `Internet Plug-Ins' folder and breaking
Netscape 6.2 as a result.

Updated

17 years ago
Blocks: 112937
*** Bug 113130 has been marked as a duplicate of this bug. ***
*** Bug 113131 has been marked as a duplicate of this bug. ***

Comment 41

17 years ago
Unless something has changed, on Mac we should still be putting the Default
Plugin in the local Plugins folder to the binary. Unless the user has decided to
move it, that shouldn't be a probelm. What could be a problem is an upgrade
situation on Win32 because plugins aren't usually nuked. I'll file another bug
for the Installer to remove the default plugin DLL from the bin plugins folder
in an upgrade situation. 

Thanks for all the comments guys! I'm not really an UI engineer so I wasn't
really planning on totally redesigning the process and implementing details. I
may have gone too far with the tooltips and status bar and I'll remove them if
you like. But, I did take a some time to think about the message box that comes
up. I'd like to try to keep this first landing of the XBL Plugin Finder close to
the C++ Default Plugin. Plus, the process of getting a plugin is already
confusing enough that I thought an extra message tot he user explaining the
process would do more good than harm. Please file RFE bugs after this lands for
your suggestions. Also, since changes can now be made an runtime, it should be
easier to modify and maybe the XPFE group can take partial ownership.

This is blocking many bugs. I'll fix what Boris mentioned in comment #35 and the
new lines. Andrei, Jag, Hyatt, can you review?
Keywords: patch, review

Updated

17 years ago
Depends on: 113963
No longer depends on: 113963

Updated

17 years ago
Blocks: 113963

Comment 42

17 years ago
pluginfinder.xml/css don't belong in xpfe/global/resources/content/bindings,
that is for global xul widgets.  You probably should be accessing it from
chrome://global/content either. I'd recommed you put these files in
layout/html/document/src and register them under a new domain like
chrome://layout/content or something like that.

Updated

17 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.8

Updated

17 years ago
Target Milestone: mozilla0.9.8 → mozilla0.9.9

Updated

17 years ago
Blocks: 112556

Comment 43

17 years ago
Pinging Peter. This bug is severity major, 0.9.9 targeted, has a semi-complete
patch, and blocks 19 other bugs. No movement in over two months. Does this have
a chance in hell of making it?

Comment 44

17 years ago
I've been busy with important embedding work, but it looks like I'll have time
to look at this this week.

The files needs to be moved to another location. I'm planning on registering
this under something like chrome://plugin/pluginfinder/

Comment 45

17 years ago
nominating nsbeta1
Keywords: nsbeta1

Comment 46

17 years ago
Ran into a problem with the APPLET tag and alternate text. Currently we show the
default plugin unless Java is disabled in which case we show the contents of the
tag (or ALT attribute text). Seems when I use the XBL rule, the alternate text
is already rendered. When trying to prevent the rendering, it doesn't look like
the XBL rule ran.
Keywords: patch, review
Target Milestone: mozilla0.9.9 → mozilla1.0
is there really no other way to attach an XBL binding then to set an attribute? 
Couldn't you use nsIDOMDocumentXBL::addBinding?

Comment 48

17 years ago
nsbeta1+ per ADT Triage
Keywords: nsbeta1 → nsbeta1+
peterl, if the change needs baking in a milestone release (to get >300,000
downloads' worth of testing), let's do this in 0.9.9.  Please let
drivers@mozilla.org know when you've got a tested and reviewed patch ready.

/be
Blocks: 122050

Comment 50

17 years ago
Comment on attachment 59702 [details] [diff] [review]
new patch

This isn't quite ready yet. Needs a bit more work.

I'm planning on putting this in modules\plugin\samples\default\xbl with its own
jar file, so maybe I can start checking in what I have if it's not part of the
build?

Jonas,
The binding is being run just fine in most cases when
nsCSSFrameConstructor::CantRenderReplacedElement runs. This seems to create the
frames for the binding rule. However, this also has the side-effect or
rendering the alternate content of APPLET tags. For example:

<applet codebase="." code="JitterText.class" width=200 height=80>
<img src="http://www.mozilla.org/images/mozilla-banner.gif" width="500">
</applet>

The image is visible through the pluginfinder and changes the size of the
plugin in layout. This is only desired when Java is off or the pluginfinder is
disabled, but it happens all the time. :(

I've tried to replace the call to CantRenderReplaceElement by appending a
content changed reflow command, with no luck. How else can I get the frames
constructed for my binding?
Attachment #59702 - Attachment is obsolete: true
Attachment #59702 - Flags: needs-work+

Comment 51

17 years ago
Ahh, this seems to do what I want:
<html:span style="display: none;"><children></children></html:span>

Applying the style directly to the children tag or removing the tag didn't work.
Is there a better way to hide children?
*untested* example of how to add the binding without modifying the document:

---
nsCOMPtr<nsIPluginTagInfo2> pit2 = do_QueryInterface(aOwner);
NS_ENSURE_TRUE(pit2, NS_ERROR_FAILURE);

nsCOMPtr<nsIDOMElement> element;
pit2->GetDOMElement(getter_AddRefs(element));
NS_ENSURE_TRUE(element, NS_ERROR_FAILURE);

nsCOMPtr<nsIDOMDocument> document;
element->GetOwnerDocument(getter_AddRefs(document));
nsCOMPtr<nsIDOMDocumentXBL> xblDoc = do_QueryInterface(document;
NS_ENSURE_TRUE(xblDoc, NS_ERROR_FAILURE);

xblDoc->AddBinding(element, NS_LITERAL_STRING
("chrome://global/content/bindings/pluginfinder.xml#PluginFinder");
---
This is on the 0.9.9 bug list.  Where are we with this?
Whiteboard: [driver:blizzard]
No longer blocks: 122050
*** Bug 129027 has been marked as a duplicate of this bug. ***

Comment 55

17 years ago
This is going to have to be bumped out to moz1.1, a rewrite is just too risky at 
this point. Setting this to nsbeta1-
Priority: P3 → P2
Target Milestone: mozilla1.0 → mozilla1.1

Updated

17 years ago
Keywords: nsbeta1+ → nsbeta1-
*** Bug 133456 has been marked as a duplicate of this bug. ***

Comment 57

17 years ago
Any chance to see this on the trunk soon?

Updated

17 years ago
Blocks: 145719

Comment 58

16 years ago
*** Bug 156441 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Blocks: 56106

Comment 59

16 years ago
setting to PL2:P1
Severity: major → critical
Whiteboard: [driver:blizzard] → [driver:blizzard][PL2:P1]
Target Milestone: mozilla1.1alpha → mozilla1.0.3

Updated

16 years ago
Target Milestone: mozilla1.0.3 → mozilla1.1alpha

Updated

16 years ago
Blocks: 115396

Updated

16 years ago
Severity: critical → normal

Updated

16 years ago
Priority: P2 → P1

Comment 60

16 years ago
*** Bug 58291 has been marked as a duplicate of this bug. ***

Comment 61

16 years ago
*** Bug 61103 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 62

16 years ago
I'm noticing a lot of movement in this bug, but no patch since November of last 
year. Curious what the status is...

Also, Peter: I have no idea what your XBL code looks like at this point, but 
regarding your comment 51, please write empty tags as <foo/>, not <foo></foo>. 
It's prettier that way :)

And just a suggestion: perhaps plugin-puzzle.gif ought to go with the browser 
theme...?

Comment 63

16 years ago
*** Bug 112556 has been marked as a duplicate of this bug. ***

Comment 64

16 years ago
Missed 1.1, and not nsbeta1+'d. Moving to next alpha.
Target Milestone: mozilla1.1alpha → mozilla1.2alpha

Updated

16 years ago
Blocks: 146517

Comment 65

16 years ago
*** Bug 146527 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Target Milestone: mozilla1.2alpha → mozilla1.2beta

Comment 66

16 years ago
*** Bug 160618 has been marked as a duplicate of this bug. ***

Comment 67

16 years ago
*** Bug 85269 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Blocks: 163993

Comment 68

16 years ago
*** Bug 170680 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Target Milestone: mozilla1.2beta → mozilla1.3alpha

Updated

16 years ago
Blocks: 154896
*** Bug 175206 has been marked as a duplicate of this bug. ***

Updated

16 years ago
No longer blocks: 146517
(Reporter)

Comment 70

16 years ago
Hi Peter, this bug has gotten a lot of dupes over the past year, and it seems to
block a number of other bugs. You've even got a patch in the works, and it looks
like discussion has led to an agreement that much of the functionality of the
current null plugin is unnecessary to reimplement. So it'd be nice to know: what
is going on with this bug? Have you been hibernating, or is the bug simply mired
in Netscape politics? Cheers!

Comment 71

16 years ago
I've been looking for a way to solve the technical problem of remembering
preferences because security won't let me access them directly because I'm in
the context of the remote page. I'm looking at how XBL form controls work and
the nsIAnonymousContent/Creator interfaces. Ideas?
(Reporter)

Comment 72

16 years ago
Peter: what preferences? What functionality are you trying to put into the
plugin finder that requires access to prefs?

Or, let me rephrase: please describe what you are planning to implement. My
feeling is that you might be able to take a good first cut at this, and get 80%
of the functionality you /think/ you need, for 20% of the work. This talk about
prefs and security makes me think you're trying to do something nobody cares about.

Comment 73

16 years ago
The "null plugin" remembers when you have told it that you don't want to
reminded about a particular mime type.

Otherwise you get a message every time you go to a page with a particular mime type.

The plugin has to store somewhere your response to the "don't ask me again"
question.

Comment 74

16 years ago
Ick!

I thought the whole point of this bug was the get the embeded helper working.
That is, no prompts at all until you click on the broken puzzle piece which
signifies the missing content due to lack of plugin.

I filed a bug to do that ages ago (because linux moz is still unusable without
flash, as on many sites every damned page gives you a plugin helper popup), and
it was duped to this.

Comment 75

16 years ago
rm -rf null-plugin
and you will be safe of pop-ups ;)
Except for the "You don't have a null plugin installed" popup....
(Reporter)

Comment 77

16 years ago
Ok people, can we think about this from perhaps a slightly more reductionist
perspective? Perhaps... just perhaps... it might be both easiest for the
developer and least intrusive for the user, to eliminate the popup entirely?

Rather than popping up a dialog asking "do you want to install the plugin? [yes]
[bugger off] [don't ask me again]" you could just have the blank plugin area be
the trigger, with some text like "click here to install the plugin." You could
make an XBL widget to do that in less than an hour, you wouldn't have to muck
around in layout to get the thing to show up, and best of all, you wouldn't be
bothering users with useless popups.

Am I missing something horribly important here?
Well, that's what you asked for in comment 0, no?  But that would be too easy
and would interfere with people's emotional attachment to this incredibly
annoying dialog... so that (key) part got ignored in comment 1, comment 3, and
following....

Frankly, I totally fail to see the problem here.  Any common plugin will already
be installed on the user's machine (Flash, Java).  If it is not, the user
obviously does not want it and doesn't want to hear about it.  Any uncommon
plugin, the web page will typically explictly tell the user she needs (SVG,
MathML, etc).  I'm fine with taking an <object> or <embed> with no alternate
content (alt attribute, child nodes) and rendering it as a clickable area that
says "click here to get the plugin" and brings up a dialog, helper, web page,
whatever.  We could even have a context menu option for "get plugin" on these
tags for cases when there _is_ alternate content.  But having the dialog come up
by default just makes no sense.

Comment 79

16 years ago
I thought the behavior Dan and Boris describe was the default on Windows (or at
least, was at one point). I thought it was something to do with platform
dependent code that left Linux with the crummy pop-up annoyance.

Peter, this is assigned to you. Can you comment directly on this method? Do you
have any issues implementing it that way? It seems a lot more friendly and
intuitive then ever trying to remember the users choice from the popup. (What if
they change their mind?)
You should be able to access prefs from xbl inside chrome://.  

Peter, do you have time for this, or should I take a look (for the xbl part at
least)?

Comment 81

16 years ago
An OBJECT with no alternative content should not be rendered at all (in the
event that the primary content cannot be rendered). Having no alternative
content means "render nothing as the alternative".

I believe this bug is only about EMBED.
Much as I dislike our current dialog, that citation is one of the perfect
examples of the HTML WG being completely on crack.  In this case, usability
calls for a way to notify the user that something is missing and that that can
be remedied by clicking _here_.

Comment 83

16 years ago
Nope. If it were important that something is missing, alternate content could be
used to indicate that.
Which is another way of saying "screw backwards compat and usability"...  But yes.

Comment 85

16 years ago
No matter how smart you make the browser with regard to usability, maintaining
usability is ultimately the page author's responsibility. In the case of OBJECT,
emphasis has been placed on graceful degradation; arguably at the expense of
imposing a usability feature on negligent authors. I think it's likely that
emphasis was a reaction to EMBED.

Comment 86

16 years ago
What do you thinks about making preference setting:
"Ask me - if I want to download required plugin?"
With default is "on"

I thinks prominent users(who do not like flash e.g) will know where to turn it off
 and ordinary users will have most of plugins anyway :)
(Reporter)

Comment 87

16 years ago
Malvin: you've missed my point. The semantics, in very informal pseudocode, of
what we try to accomplish is this:

  plugin not available () {
    if (user wants the plugin)
      go get the plugin;
    else
      don't get the plugin;
  }

We explicitly go through that whole process by posing the dialog. But we can
simplify the logic:

  plugin not available () {
    if (user wants the plugin)
      go get the plugin;
  }

We don't need to know if the user doesn't want the plugin, because if the user
doesn't want the plugin, there's nothing we actually do in that case. An analogy
(though absurd) would be if we were to pop up a dialog for every link in a
webpage asking, "do you want to open this link?" Understand?

On a different topic, I'm not sure Braden's interpretation of the HTML spec is
correct. From http://www.w3.org/TR/html4/struct/objects.html#h-13.3.1 :

1. The user agent must first try to render the object. It should not render the
   element's contents, but it must examine them in case the element contains any
   direct children that are PARAM elements or MAP elements (see client-side image
   maps). 
2. If the user agent is not able to render the object for whatever reason
   (configured not to, lack of resources, wrong architecture, etc.), it must try
   to render its contents.

This doesn't explicitly say that if there is no content, nothing is rendered.
Also, remember that EMBED is a Netscape proprietary HTML tag from back in the
day... I don't know off-hand how EMBED and OBJECT differ, but regardless, I
think most sites use OBJECT these days. This bug is definitely about OBJECT, and
probably also about EMBED.

Comment 88

16 years ago
dr: If you think my interpretation is incorrect, then explain how one should use
OBJECT such that nothing is rendered in the event that the DATA cannot be rendered.

OBJECTs may be strictly decorative; it is not appropriate for the browser to
second-guess page authors and assume that users need to be alerted to the
absence of a rendering.

Comment 89

16 years ago
------
http://devedge.netscape.com/viewsource/2002/gecko-plugins/

 Note that the use of the OBJECT  tag assumes that the plugin exists on the
desktop, and doesn't tell you where to get it if it is missing.  The EMBED tag
allows you to provide the pluginspage attribute, telling users where to obtain
the plugin if it is not present. Future Netscape Gecko browsers will allow the
use of the codebase attribute with the OBJECT  tag as an equivalent for the
pluginspage or pluginurl attributes in the EMBED  tag.
-------
BTW. There is a way to check from JS is there plugin you need.
That means webmaster could make this check to choose show or not layer with
embed in it.
 If they do not - that means they want user to get plugin.

 BTW If you thinks that user _know_ if he need a plugin - you are wrong :)
Most of users do not know what is the "plugin". So they need to be asked about
this. Most of them will answer - yes.
 
 So I'll still thinks that
if(no plugin)
{
 if(prefs.ask_me==true)
  {
    if (user wants the plugin)
      go get the plugin;
    else
      don't get the plugin;
  }
}

that means 1 preference for all plugins.
Still you could click on plugin area to dialog box

Comment 90

16 years ago
Getting (even more) sidetracked here, but note that excerpt from the Netscape
developer documentation is as misguided as Mozilla's current implementation of
CODEBASE. See bug 162993.
(Reporter)

Comment 91

16 years ago
> dr: If you think my interpretation is incorrect, then explain how one should use
> OBJECT such that nothing is rendered in the event that the DATA cannot be
> rendered.

I understand your point, but it's moot. Does the HTML spec explicitly state that
nothing should be rendered, in that case? NO. It just says that we should try to
render the object, and failing that, try to render its content. It doesn't say
what to do if that fails. We could put dancing pandas where the object should
be, for all the spec cares.
I think you're confusing DATA with alternate content.  Nobody has raised the
issue of errors rendering the alternate content, though the pandas would be cute.

Comment 93

16 years ago
dr: If the alternate content is nothing, the browser then renders nothing when
rendering the alternate. How would the browser fail to render nothing?

Comment 94

16 years ago
So we are going to need access to preferences because undoubtly we all can't
agree on how this should work. I think everything should be the way it is now
but with the added ability to easily add cross platform UI funtionality later.
The last patch breaks what mkapley talks about and that would require UI reviews
to change. I welcome any help from any xbl/anonymous content experts.

Currently we do show the default plugin on the OBJECT tag only in the case which
the author is using a PLUGINURL PARAM tag.

There is also a pref to turn off the dialog asking you to get the default plugin
if it's removed which should stop all plugin popups.
Keywords: helpwanted
(Reporter)

Comment 95

16 years ago
> So we are going to need access to preferences because undoubtly we all can't
> agree on how this should work.

Sounds like the starts of a great new W3C spec: "well, we can't come to
agreement or compromise, let's build in support for every possible approach."
Come to think of it, that logic is endemic in Mozilla... Building a better
browser (or a better web standard, or a better anything) is not synonymous with
solving every browsing-related problem every possible way.

> I think everything should be the way it is now but with the added ability to
> easily add cross platform UI funtionality later.

What do you mean by that? You still didn't answer my original question in
comment 72: what functionality do you actually think you need? You seem to think
you need something significant. I think you're just making unnecessary work for
yourself.

> The last patch breaks what mkapley [sic] talks about and that would require UI
> reviews to change.

Oh, the horror of UI reviews. What mkaply describes in comment 73 is specific to
one possible implementation: the approach where we pose a dialog, and the user
has to do a small amount of work to not be further bothered by the dialog. But
if we don't pose a dialog at all, we don't bother users, and the preferences
problem solves itself.

> There is also a pref to turn off the dialog asking you to get the default
> plugin if it's removed which should stop all plugin popups.

I hope this isn't too radical a question to ask, but, does that really seem like
an example of good software design to you, Peter? We have this null plugin that
does little besides annoy users, and a failsafe in the event of its removal that
further annoys users.

> I welcome any help from any xbl/anonymous content experts.

I reiterate that it doesn't take an expert to make an XBL widget, and that you
shouldn't need to do anything special to accomplish what you need to. That's the
whole point of the 20 man-years, give or take a few, committed to the XPToolkit.

Now, if memory serves, Peter, you've been working at Netscape since 24 July
2000. This bug has been sitting in your lap since 18 July 2001. Furthermore,
since 5 September 2001 the bug has been targeted to a milestone... first 0.9.6,
then 0.9.7, 0.9.8, 0.9.9 and so forth. So I think it's fair to say that you've
had a bit of time to familiarize yourself with Mozilla basics, and a bit of time
to think about this bug. At the very least, you've had time to reassign this bug
to somebody who thinks that over 50 people CC'ed and over 20 bugs blocked might
be important.

I find it extraordinarily frustrating and paradoxical, as somebody who was very
justifiably laid off from Netscape, that you still find gainful employment
there. It seems a disservice to the outstanding engineers, managers and other
contributors that have poured their souls into the project.
Assignee: peterlubczynski → nobody
Status: ASSIGNED → NEW

Comment 96

16 years ago
Putting back into Peter's queue.
Assignee: nobody → peterl

Comment 97

16 years ago
It's not that simple. We need to keep track of seen mime types and do popups for
cases when there is no puzzle piece to click on like:
<EMBED HIDDEN=TRUE SRC=audio.wav">

This is a complicated issue on how to inform the user yet not get too much in
their face and different embedders of Mozilla have differenet requirments. Even
IE on the Mac and Opera ship with their own "default plugin" in a seperate library.

Another problem is that CSS being used in the above patch doesn't exactly mirror
how the current default works in layout. When testing this I came up with
several testcases where there were sizing, alignment, and overlap problems,
especially with small sizes. 

Another thing is that bug 168490 causes the default plugin to now look at the
header returned from the PFS. This would have be re-implemented somehow.

Also, the solution in bugscape 20067 needs security in order to execute a file
to fix the "Real first-install problem" (aka Real is installed but no
nppl3260.dll is found). Embedders also execute files from the default plugin.

Dan, if you think this is so easy to fix why don't you attach at patch instead
of launching personal attacks at me? Afterall, outside contributors have smaller
hurdles to jump through to get code checked in. I've been busy fixing crashers
and serious problems instead of features like this one that might cause more
harm than good.

Comment 98

16 years ago
I think that for <embed hidden="true"> and <bgsound> if we don't handle the data
we should ignore the hidden and give people a puzzle piece. i don't think the
user would mind the puzzle piece. and I think the content authors can live with
the piece appearing. if they don't want it, then they can use js to detect the
plugin and conditionally display it. or they could use <object> and get whatever
standards behavior we eventually trigger.

So that leaves object:
<object type="data:application/vnd.timeless.foo,pie">
<object type="data:application/vnd.timeless.bar,bie">
<object type="data:application/vnd.timeless.baz,zie">
alternate
</object></object></object>

I think that a puzzle piece as a rendition of <object> may be fine. Here's my
attempt at rendering the above (note that this is how it would appear in the
page, it would not be a dialog, and if there's lots of space the puzzle piece
would probably appear above the text):
.----------------------------------------|
| /xx/ No plugin available for           | <- standard (localized text)
|(xx(  [application/vnd.timeless.foo |v] | <- content type listbox
| \xx\ (find plugin) (view alternate)    | <- two buttons
+----------------------------------------+    (perhaps styled as links)
  ^ puzzle piece
I think this satisfies http://www.w3.org/TR/html4/struct/objects.html#h-13.3.1
(comment 87) point 1:
The user agent must first try to render the object. It should not render the
element's contents, but it must examine them in case the element contains any
direct children that are PARAM elements or MAP elements (see client-side image
maps). 
* I've examined the children without rendering them. 
* I've tried to render the object.

Of note. how does point 1 resolve with point 2 
If the user agent is not able to render the object (configured not to).

Suppose I configure application/vnd.timeless.foo so that it never renders and i
install a plugin (or many plugins) which can render that type, isn't the browser
required by 1 to try to render the object (point 1) instead of trying to listen
to the user (point 2) and not render it?

when the user clicks view alternate, then the useragent categorizes the
object(s) as unrenderable (per user) and renders the first renderable level
(this means that the user doesn't have to click view alternate 3 times in my
case just to see 'alternate') per 2:
If the user agent is not able to render the object for whatever reason
(configured not to, lack of resources, wrong architecture, etc.), it must try
to render its contents.

As for configuring not to, that's the only problematic one, it's very easy though.

the plugin manager (some other bug) generates css bindings which map
object[type="application/vnd.timeless.foo"],
*[-moz-real-type="application/vnd.timeless.foo"]{
-moz-binding: url(chrome://global/content/bindings/plugins.xml#ignoreobject);
}

-moz-real-type is some way to expose the actual media type for an object (embed,
applet, iframe, img, button, ...) to the css object model. We don't really need
it immediately, but it'd be a very nice thing to have.
here is ignore object:

<!DOCTYPE bindings>
<bindings xmlns="http://www.mozilla.org/xbl"
xmlns:html="http://www.w3.org/1999/xhtml">
<binding id="ignoreobject"><content><children/></content></binding>
</bindings>

The only fun part left is allowing the user to make changes to plugin settings
(read: block/ignore plugins) without requiring the xbl to have chrome privs.

we address this by changing the context menu (which runs as chrome) to be able
to probe the xbl and allow the user to select "manage plugins" which would popup
the plugin manager with the selected object's types listed and selected (for
easy blocking), followed by all other page plugin types, and then all other
configured plugin types.
(Reporter)

Comment 99

16 years ago
> It's not that simple. We need to keep track of seen mime types and do popups
> for cases when there is no puzzle piece to click on like:
> <EMBED HIDDEN=TRUE SRC=audio.wav">

My advice, if you'll pardon the awful pun, is that you think outside the
"box"... Maybe a popup is most appropriate in this case, maybe not. But in my
opinion, which you're free as always to take with a boulder of salt, is that if
access to prefs is the only thing preventing you from covering 100% of your
cases, perhaps you could do a first pass without prefs and then let the
community help get all the rest of your needs covered.

> Another problem is that CSS being used in the above patch doesn't exactly
> mirror how the current default works in layout. When testing this I came up
> with several testcases where there were sizing, alignment, and overlap
> problems, especially with small sizes. 

Ok, you raise a very good issue. That's a good separable task for somebody to
look at. You could delegate that work to one of the fifty-odd people interested
in this bug! Thank you for finally putting some substantive information in this bug.

> Another thing is that bug 168490 causes the default plugin to now look at the
> header returned from the PFS. This would have be re-implemented somehow.

Again, thanks for the information here.

> Dan, if you think this is so easy to fix why don't you attach at patch instead
> of launching personal attacks at me? Afterall, outside contributors have
> smaller hurdles to jump through to get code checked in. I've been busy fixing
> crashers and serious problems instead of features like this one that might
> cause more harm than good.

Ah, you're bringing back some sweet memories. Look, I'm sorry for making you
feel more "under the magnifying glass" than you'd like to feel. But speaking as
somebody who's familiar with the environment you're working in, you can't just
ignore a bug of this magnitude for so long without making some substantive
comments that we can all see. If you need help, or you want to take the line of
defense of "if you don't like it, write the patch yourself," you still have to
back it up with information from your own experience and knowledge. You only
just gave us a clear picture of why this bug has stagnated in comment 97, and
only after much pushing.

Comment 100

16 years ago
To Dan:

As you well know we have to prioritize issues and features. And as you well know
from being within this environment, engineers are not necessarily allowed to
work on the bugs they would like to work on. We have our focus and we have or
requirements that must be met. Peter is addressing the bugs that have been
deemed needed and necessary. Replacing the dialog, in the grand scheme of issues
involving plug-ins, is not a showstopper. This bug will get resolved in due
time. The more pressing and critical bugs should be resolved first. Those
particular issues include hangs, crashes, interoperability, etc.

To all:

If individuals feel the need to voice their frustration, send a note my way as I
am the person directing which bugs Peter should focus on. If you disagree with
our prioritization, let me know. But please, refrain from personal attacks, that
is neither productive or good manners.

Comment 101

16 years ago
moving to future, will readdress after plug-in branch work is done
Target Milestone: mozilla1.3alpha → Future

Comment 102

16 years ago
*** Bug 191125 has been marked as a duplicate of this bug. ***

Comment 103

16 years ago
*** Bug 175048 has been marked as a duplicate of this bug. ***
*** Bug 195360 has been marked as a duplicate of this bug. ***

Comment 105

16 years ago
This might be similar - when running the Intellicast weather page, the java
clock on the bottom causes a box to be displayed...

Visual C++ Runtime Library

Assertion Failed
erno=0&& count=(size_t)size

If you click ignore, sometimes Mozilla shuts down, sometimes it displays the page.

Comment 106

16 years ago
*** Bug 200613 has been marked as a duplicate of this bug. ***
*** Bug 206984 has been marked as a duplicate of this bug. ***
*** Bug 214141 has been marked as a duplicate of this bug. ***

Comment 109

15 years ago
For those who are constantly annoyed by the plugin download dialog popping up, I
have a workaround that should probably be obvious, but I have only just found it
now, so perhaps it will help someone else, too: just move the libnullplugin.so
file (or whatever it's called on your platform of choice) out of the plugins
directory. That's it. I don't know if there are any side-effects - I haven't
noticed any problems so far.

Comment 110

15 years ago
you're better off replacing it w/ the n4 plugin if such a plugin is available.
historically mozilla would complain w/ a dialog if it couldn't find a null plugin.

Comment 111

15 years ago
Timeless: not that I've ever noticed, but perhaps I've set some pref to disable
such a warning. For what it's worth, I've routinely removed libnullplugin.so
every time I install a nightly build for years (which is itself a highly
annoying step to constantly have to take), without noticing any adverse effects.
I've yet to figure out why Mozilla bothered to implement web page popup blocking
but continues to ship plugin code which subjects its users to the same annoyance.

Flash click-to-run is the real usability win here. Now I can install the
click-to-run XUL along with the flash plugin, and not get popups about flash,
but still not have to view them. Unfortunately every day I still have to
reinstall the plugin since Mozilla /still/ has not implemented loading plugins
from a user's profile.
*** Bug 225155 has been marked as a duplicate of this bug. ***

Comment 113

15 years ago
*** Bug 228113 has been marked as a duplicate of this bug. ***

Comment 114

15 years ago
Most of the dups of this bug are asking to remove the Linux-only "missing
plugin" dialog (or make it possible to disable the dialog).  Since this bug is
cross-platform and futured, that doesn't make much sense.

Comment 115

15 years ago
*** Bug 228950 has been marked as a duplicate of this bug. ***

Comment 116

15 years ago
*** Bug 231461 has been marked as a duplicate of this bug. ***

Comment 117

15 years ago
*** Bug 235026 has been marked as a duplicate of this bug. ***

Comment 118

15 years ago
Created attachment 145057 [details] [diff] [review]
Unix nullplugin - Open/save content option and no auto pop-up unless plugin is hidden

Hi, I made this simple patch to scratch an itch - I was annoyed at having to
view source to get at videos. Many websites only let you view content using a
plugin and not with a link. This patch adds to the download plugin dialog an
option that opens the plugin's content . It redirects the browser to the file
specified in <EMBED src=url> or <OBJECT data=url> so that the user is presented
with the usual open/save dialog, or the default action is carried out if one is
set for that MIME type.

Since the pop-up can be annoying I also made it not automatically open the
dialog unless the plugin is very small (< 16 pixels), hidden by css or hidden
by EMBED's hidden attribute. It requires a click to open the dialog most of the
time but not when the user can't see anything to click on. I know some people
want a preference for this but I think its better to automatically do something
intelligent.

It is a patch to the default plugin within the mozilla tree rather than a
standalone plugin. I have tested it using Firebird 0.8 on the plugger testing
ground, ministry of sound, and BBC radio. At the BBC WMA works but not real
because they use javascript to control the real plugin. 

Why did I not use XBL? The default plugin was very simple to hack and I didn't
feel like spending ages learning the finer details of mozilla and XBL. I know
XBL is the right way to go and my patch might be rejected for being unix
specific but it makes my browsing experience much nicer so I put it forward for
consideration, even if it is only a temporary solution for nix people. It might
give people ideas for the XBL interface too.

The changes are pretty simple so if someone wants to port them to other default
plugins it shouldn't be too hard. I'm only running Linux so can't do it.

Robert
Please file a separate bug and attach that patch there.

Comment 120

15 years ago
Comment on attachment 145057 [details] [diff] [review]
Unix nullplugin - Open/save content option and no auto pop-up unless plugin is hidden

Apologies for putting this in the wrong bug. I've moved it to bug 236543
Attachment #145057 - Attachment is obsolete: true

Updated

15 years ago
Severity: normal → enhancement

Comment 121

15 years ago
*** Bug 241908 has been marked as a duplicate of this bug. ***

Comment 122

15 years ago
:-(

Comment 123

15 years ago
*** Bug 243902 has been marked as a duplicate of this bug. ***

Comment 124

15 years ago
I think making this out of XUL or XBL would fix the 3 accessibility issues in
bug 245349 -- it's not tabbable, you can't hit Enter on it to "click", the
button is not exposed as anything.
Blocks: 245349
As a note to self - the code to be changes is in nsPluginHostImpl.cpp#3361

Comment 126

14 years ago
Any year now...

Comment 127

14 years ago
*** Bug 251720 has been marked as a duplicate of this bug. ***

Comment 128

14 years ago
Since the comments are too long and I'm not a mozilla developer.
Could someone summarize:
- what's up to now?
- who is working on this bug?
- is this plugin expected to be finished?
- what's the current status of this bug?
This bug may be fixed once a year passes by without useless comments having been
added.

Comment 130

14 years ago
Maybe you are not affected, but for my architecture there is no Flash/Shockwave
plugin. For every second web page I get a popup asking whether I would like to
download and install a plugin, even though I know that the attempt would be in
vain. And there is no serious way to suppress this dialog (except for removing
nullplugin, or maybe disabling Javascript).

This is an ugly problem. All I would like to have is a checkbox "do not show
this popup again", as in Konqueror.
(In reply to comment #130)
> Maybe you are not affected, but for my architecture there is no Flash/Shockwave
> plugin. For every second web page I get a popup asking whether I would like to
> download and install a plugin, even though I know that the attempt would be in
> vain. And there is no serious way to suppress this dialog (except for removing
> nullplugin, or maybe disabling Javascript).
> 
> This is an ugly problem. All I would like to have is a checkbox "do not show
> this popup again", as in Konqueror.
> 

We're working on being smarter about how we deal with this, exactly what it'll
look like we don't know at this point, but yeah, one modal dialog per unknown
plugin is rather lame, to say the least. Stay tuned.

Comment 132

14 years ago
Hey! I have 1.7 and no pop-up dialogs asking about pluging! What I do wrong? :)
(OS win*). And npnul32.dll is installed.
I think it is default isntallation + prefbar + downloadbar + gestues.
May it be that internal popup blocker also block plugin popups? ;)
(In reply to comment #132)
> Hey! I have 1.7 and no pop-up dialogs asking about pluging! What I do wrong? :)
> (OS win*). And npnul32.dll is installed.
> I think it is default isntallation + prefbar + downloadbar + gestues.
> May it be that internal popup blocker also block plugin popups? ;)

That's because you're on Win32, the dialogs only show up on Unix based systems
(and maybe other non-Win32 systems) AFAIK :-)

Comment 134

14 years ago
When you fix this bug please also don't show the dialog when scrollwheeling over
a missing plugin.  That's *really* annoying!

Updated

14 years ago
Blocks: 177834

Comment 135

14 years ago
*** Bug 205984 has been marked as a duplicate of this bug. ***

Comment 136

14 years ago
*** Bug 287795 has been marked as a duplicate of this bug. ***

Updated

14 years ago
No longer blocks: 163993

Updated

12 years ago
Duplicate of this bug: 338567
fixed by bug 1156/bug 309521
Status: NEW → RESOLVED
Last Resolved: 17 years ago11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.