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)
Core Graveyard
Plug-ins
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)
1.07 KB,
image/gif
|
Details |
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
Comment 1•23 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?
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•23 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•23 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.
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?
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•23 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.
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•23 years ago
|
||
Full-page plugins don't invoke the null plugin. They go down the helper path.
Comment 11•23 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•23 years ago
|
||
I agree, full-page plugins go the route of a helper app and no default plugin should interfear.
Comment 13•23 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•23 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•23 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
Comment 16•23 years ago
|
||
add to cc list
Reporter | ||
Comment 17•23 years ago
|
||
*** Bug 62513 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 18•23 years ago
|
||
no.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Comment 19•23 years ago
|
||
Any thougths?
Reporter | ||
Comment 20•23 years ago
|
||
[spam] working on toolkit: plugins bugs => plugins team.
Assignee: dr → peterlubczynski
Status: RESOLVED → NEW
Target Milestone: mozilla0.9.3 → ---
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Comment 21•23 years ago
|
||
Assigned bugs shouldn't have a resolution, should this be assigned or resolved wontfix?
Updated•23 years ago
|
Resolution: WONTFIX → ---
Updated•23 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•23 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•23 years ago
|
Target Milestone: Future → mozilla0.9.6
Comment 24•23 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]
Comment 25•23 years ago
|
||
*** Bug 101833 has been marked as a duplicate of this bug. ***
Comment 26•23 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•23 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•23 years ago
|
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Updated•23 years ago
|
Keywords: helpwanted
Summary: Remove default (null) plugin. → Replace C++ version of default (null) plugin with XBL one
Comment 28•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
Reporter | ||
Comment 31•23 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•23 years ago
|
||
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•23 years ago
|
||
*** Bug 73129 has been marked as a duplicate of this bug. ***
Comment 34•23 years ago
|
||
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
Comment 35•23 years ago
|
||
+ 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•23 years ago
|
||
looks pretty good to me, but you /really/ ought to ask jag for a real thorough r=.
Comment 37•23 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•23 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.
Comment 39•23 years ago
|
||
*** Bug 113130 has been marked as a duplicate of this bug. ***
Comment 40•23 years ago
|
||
*** Bug 113131 has been marked as a duplicate of this bug. ***
Comment 41•23 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?
Comment 42•23 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•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Updated•23 years ago
|
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Comment 43•22 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•22 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 46•22 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.
is there really no other way to attach an XBL binding then to set an attribute? Couldn't you use nsIDOMDocumentXBL::addBinding?
Comment 49•22 years ago
|
||
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•22 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•22 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"); ---
Comment 53•22 years ago
|
||
This is on the 0.9.9 bug list. Where are we with this?
Whiteboard: [driver:blizzard]
Comment 54•22 years ago
|
||
*** Bug 129027 has been marked as a duplicate of this bug. ***
Comment 55•22 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•22 years ago
|
Comment 56•22 years ago
|
||
*** Bug 133456 has been marked as a duplicate of this bug. ***
Comment 57•22 years ago
|
||
Any chance to see this on the trunk soon?
Comment 58•22 years ago
|
||
*** Bug 156441 has been marked as a duplicate of this bug. ***
Comment 59•22 years ago
|
||
setting to PL2:P1
Severity: major → critical
Whiteboard: [driver:blizzard] → [driver:blizzard][PL2:P1]
Target Milestone: mozilla1.1alpha → mozilla1.0.3
Updated•22 years ago
|
Target Milestone: mozilla1.0.3 → mozilla1.1alpha
Updated•22 years ago
|
Severity: critical → normal
Updated•22 years ago
|
Priority: P2 → P1
Comment 60•22 years ago
|
||
*** Bug 58291 has been marked as a duplicate of this bug. ***
Comment 61•22 years ago
|
||
*** Bug 61103 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 62•22 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•22 years ago
|
||
*** Bug 112556 has been marked as a duplicate of this bug. ***
Comment 64•22 years ago
|
||
Missed 1.1, and not nsbeta1+'d. Moving to next alpha.
Target Milestone: mozilla1.1alpha → mozilla1.2alpha
Comment 65•22 years ago
|
||
*** Bug 146527 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Target Milestone: mozilla1.2alpha → mozilla1.2beta
Comment 66•22 years ago
|
||
*** Bug 160618 has been marked as a duplicate of this bug. ***
Comment 67•22 years ago
|
||
*** Bug 85269 has been marked as a duplicate of this bug. ***
Comment 68•22 years ago
|
||
*** Bug 170680 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Target Milestone: mozilla1.2beta → mozilla1.3alpha
Comment 69•22 years ago
|
||
*** Bug 175206 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 70•22 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•22 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•22 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•22 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•22 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•22 years ago
|
||
rm -rf null-plugin and you will be safe of pop-ups ;)
Comment 76•22 years ago
|
||
Except for the "You don't have a null plugin installed" popup....
Reporter | ||
Comment 77•22 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?
Comment 78•22 years ago
|
||
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•22 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?)
Comment 80•22 years ago
|
||
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•22 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.
Comment 82•22 years ago
|
||
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•22 years ago
|
||
Nope. If it were important that something is missing, alternate content could be used to indicate that.
Comment 84•22 years ago
|
||
Which is another way of saying "screw backwards compat and usability"... But yes.
Comment 85•22 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•22 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•22 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•22 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•22 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•22 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•22 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•22 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•22 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•22 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 97•22 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•22 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•22 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•22 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•22 years ago
|
||
moving to future, will readdress after plug-in branch work is done
Target Milestone: mozilla1.3alpha → Future
Comment 102•22 years ago
|
||
*** Bug 191125 has been marked as a duplicate of this bug. ***
Comment 103•21 years ago
|
||
*** Bug 175048 has been marked as a duplicate of this bug. ***
Comment 104•21 years ago
|
||
*** Bug 195360 has been marked as a duplicate of this bug. ***
Comment 105•21 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•21 years ago
|
||
*** Bug 200613 has been marked as a duplicate of this bug. ***
Comment 107•21 years ago
|
||
*** Bug 206984 has been marked as a duplicate of this bug. ***
Comment 108•21 years ago
|
||
*** Bug 214141 has been marked as a duplicate of this bug. ***
Comment 109•21 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•21 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•21 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.
Comment 112•21 years ago
|
||
*** Bug 225155 has been marked as a duplicate of this bug. ***
Comment 113•21 years ago
|
||
*** Bug 228113 has been marked as a duplicate of this bug. ***
Comment 114•21 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•21 years ago
|
||
*** Bug 228950 has been marked as a duplicate of this bug. ***
Comment 116•21 years ago
|
||
*** Bug 231461 has been marked as a duplicate of this bug. ***
Comment 117•20 years ago
|
||
*** Bug 235026 has been marked as a duplicate of this bug. ***
Comment 118•20 years ago
|
||
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•20 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•20 years ago
|
Severity: normal → enhancement
Comment 121•20 years ago
|
||
*** Bug 241908 has been marked as a duplicate of this bug. ***
Comment 122•20 years ago
|
||
:-(
Comment 123•20 years ago
|
||
*** Bug 243902 has been marked as a duplicate of this bug. ***
Comment 124•20 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
Comment 125•20 years ago
|
||
As a note to self - the code to be changes is in nsPluginHostImpl.cpp#3361
Comment 126•20 years ago
|
||
Any year now...
Comment 127•20 years ago
|
||
*** Bug 251720 has been marked as a duplicate of this bug. ***
Comment 128•20 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?
Comment 129•20 years ago
|
||
This bug may be fixed once a year passes by without useless comments having been added.
Comment 130•20 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.
Comment 131•20 years ago
|
||
(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•20 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? ;)
Comment 133•20 years ago
|
||
(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•20 years ago
|
||
When you fix this bug please also don't show the dialog when scrollwheeling over a missing plugin. That's *really* annoying!
Comment 135•19 years ago
|
||
*** Bug 205984 has been marked as a duplicate of this bug. ***
Comment 136•19 years ago
|
||
*** Bug 287795 has been marked as a duplicate of this bug. ***
Comment 138•17 years ago
|
||
fixed by bug 1156/bug 309521
Status: NEW → RESOLVED
Closed: 23 years ago → 17 years ago
Resolution: --- → FIXED
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•