Closed Bug 83754 Opened 23 years ago Closed 17 years ago

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

Categories

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

enhancement

Tracking

(Not tracked)

RESOLVED FIXED
Future

People

(Reporter: dr, Assigned: peterl-bugs)

References

Details

(5 keywords, Whiteboard: [driver:blizzard][PL2:P1])

Attachments

(1 file, 5 obsolete files)

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!
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla0.9.2
Blocks: 73129
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?
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.
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.
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.
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?
Adding George Drapeau.
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? 
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.
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?
Full-page plugins don't invoke the null plugin.

They go down the helper path.
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.
I agree, full-page plugins go the route of a helper app and no default plugin 
should interfear.
Adding Ed Burns, Igor Kushnirskiy, who both have experience with Mozilla
Plug-Ins module.  I'll make my own comments later.
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.
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
Blocks: 58291
Blocks: 62513
add to cc list
*** Bug 62513 has been marked as a duplicate of this bug. ***
Blocks: 86645
Blocks: 56231
Priority: P1 → P3
no.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Any thougths?
[spam] working on toolkit: plugins bugs => plugins team.
Assignee: dr → peterlubczynski
Status: RESOLVED → NEW
Target Milestone: mozilla0.9.3 → ---
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Blocks: 92322
Assigned bugs shouldn't have a resolution, should this be assigned or resolved
wontfix?
Resolution: WONTFIX → ---
Blocks: 56229
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 :)
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.
Target Milestone: Future → mozilla0.9.6
Blocks: 44711
Blocks: 61103
Blocks: 98976
------- 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]

Blocks: 95157
Blocks: 57455
*** Bug 101833 has been marked as a duplicate of this bug. ***
Blocks: 54147
Blocks: 69215
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.
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.
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Blocks: 108605
Keywords: helpwanted
Summary: Remove default (null) plugin. → Replace C++ version of default (null) plugin with XBL one
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.
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
Attached image plugin-puzzle.gif
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.
Attached patch localized patch (obsolete) — Splinter Review
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
*** Bug 73129 has been marked as a duplicate of this bug. ***
Attached patch new patch (obsolete) — Splinter Review
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...
looks pretty good to me, but you /really/ ought to ask jag for a real thorough r=.
Blocks: 85269
+      // 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.
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.
Blocks: 112937
*** Bug 113130 has been marked as a duplicate of this bug. ***
*** Bug 113131 has been marked as a duplicate of this bug. ***
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
Depends on: 113963
No longer depends on: 113963
Blocks: 113963
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.
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Blocks: 112556
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?
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/
nominating nsbeta1
Keywords: nsbeta1
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?
nsbeta1+ per ADT Triage
Keywords: nsbeta1nsbeta1+
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 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+
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. ***
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
Keywords: nsbeta1+nsbeta1-
*** Bug 133456 has been marked as a duplicate of this bug. ***
Any chance to see this on the trunk soon?
Blocks: 145719
*** Bug 156441 has been marked as a duplicate of this bug. ***
Blocks: 56106
setting to PL2:P1
Severity: major → critical
Whiteboard: [driver:blizzard] → [driver:blizzard][PL2:P1]
Target Milestone: mozilla1.1alpha → mozilla1.0.3
Target Milestone: mozilla1.0.3 → mozilla1.1alpha
Blocks: 115396
Severity: critical → normal
Priority: P2 → P1
*** Bug 58291 has been marked as a duplicate of this bug. ***
*** Bug 61103 has been marked as a duplicate of this bug. ***
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...?
*** Bug 112556 has been marked as a duplicate of this bug. ***
Missed 1.1, and not nsbeta1+'d. Moving to next alpha.
Target Milestone: mozilla1.1alpha → mozilla1.2alpha
Blocks: 146517
*** Bug 146527 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.2alpha → mozilla1.2beta
*** Bug 160618 has been marked as a duplicate of this bug. ***
*** Bug 85269 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
*** Bug 170680 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.2beta → mozilla1.3alpha
Blocks: 154896
*** Bug 175206 has been marked as a duplicate of this bug. ***
No longer blocks: 146517
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!
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?
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.
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.
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.
rm -rf null-plugin
and you will be safe of pop-ups ;)
Except for the "You don't have a null plugin installed" popup....
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.
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)?
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_.
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.
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.
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 :)
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.
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.
------
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
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.
> 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.
dr: If the alternate content is nothing, the browser then renders nothing when
rendering the alternate. How would the browser fail to render nothing?
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
> 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
Putting back into Peter's queue.
Assignee: nobody → peterl
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.
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.
> 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.
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.
moving to future, will readdress after plug-in branch work is done
Target Milestone: mozilla1.3alpha → Future
*** Bug 191125 has been marked as a duplicate of this bug. ***
*** Bug 175048 has been marked as a duplicate of this bug. ***
*** Bug 195360 has been marked as a duplicate of this bug. ***
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.
*** 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. ***
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.
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.
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. ***
*** Bug 228113 has been marked as a duplicate of this bug. ***
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.
*** Bug 228950 has been marked as a duplicate of this bug. ***
*** Bug 231461 has been marked as a duplicate of this bug. ***
*** Bug 235026 has been marked as a duplicate of this bug. ***
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 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
Severity: normal → enhancement
*** Bug 241908 has been marked as a duplicate of this bug. ***
:-(
*** Bug 243902 has been marked as a duplicate of this bug. ***
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
Any year now...
*** Bug 251720 has been marked as a duplicate of this bug. ***
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.
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.
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 :-)
When you fix this bug please also don't show the dialog when scrollwheeling over
a missing plugin.  That's *really* annoying!
Blocks: 177834
*** Bug 205984 has been marked as a duplicate of this bug. ***
*** Bug 287795 has been marked as a duplicate of this bug. ***
No longer blocks: majorbugs
fixed by bug 1156/bug 309521
Status: NEW → RESOLVED
Closed: 23 years ago17 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: