Closed Bug 36908 Opened 25 years ago Closed 24 years ago

about:plugins does not work


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



(Not tracked)



(Reporter: cyril_bortolato, Assigned: endico)




(Whiteboard: [nsbeta3-])


(8 files)

If you type about:plugins in the URL bar, you get:

JavaScript error: 
 line 0: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIBrowserInstance.loadUrl]"  nsresult:
"0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://navigator/content/navigator.js :: BrowserLoadURL :: line 1043"  data:

Expected result:
A page listing all the plugins installed, like in NN 4.x.

Build 2000-04-23-09 on Linux.

Additional infos:
about:fonts triggers the same error. Also, if you remove what's in the
URL bar and type enter, the error occurs as well.
CCing, because he seemed to be talking about about: URLS in 
#mozilla today. Tenuous, granted ;-) Still a problem (error appears on console) 
on 20000428, BTW.

assuming that it is up to the owners of each of those areas to impliment about: 
so I'm sending this over to Plugins for a look.
Assignee: asadotzler → av
Component: Browser-General → Plug-ins
QA Contact: jelwell → shrir
This comment is in response to a post on the mozilla-plugins mailing list
requesting community comments on the important about:plugins.  

As a plugin developer and general Mozilla consumer, I think it is very important
to have some means of viewing info on what plugins are installed on my system
and for what mime-type/file extensions.  If there is some other existing or
planned means for viewing this info (like a xul file accessed from the menu)
then that would be fine.

I'm not even that worried about this feature hitting the next beta release,
just so it's in the final product.
Added an html attachment that has the js code used in netscape 4 to produce the 
about:Plugins page.  Works in mozilla.
Adding nsbeta3 keyword - idea would be to check in the attached HTML file and 
link it up to about:plugins, or something similar.

Keywords: nsbeta3
thanks for the attachment, im working on it now
ive got this fix and will check in, once i get some more about stuff cleaned up.
so it should be in shortly.

Thanks again for pointing out the js
Adding dependency on  Until 
37504 is addressed, the list generated by the js attachment will be missing 
xpcom plugins that:
1) don't have file names that start with "np"
2) are in the bin/components directory rather than the plugins directory
Depends on: 37504
removing dependency on
adding dependency on

Depends on: 44614
No longer depends on: 37504
Keywords: 4xp
The attachment works with xpcom plugins that are registered with the proposed 
solution to
Depends on: 45698
No longer depends on: 44614
correctness of support for plug-ins. This info will be invaluable to support at
both Netscape and plug-in vendors when diagnosing problem reports.
Keywords: correctness
[nsbeta3-]. Suggested workaround: someone should put up web page on
that uses JS & XPConnect to read registry and display this info.
Whiteboard: [nsbeta3-]
I have about:plugins working. I copied the old classic plugins page
and sford's code for about:mozilla.

Note that this, and all the about protocols generate the following error.

"Error getting url widget service: TypeError: Components.classes[progid] has
no properties"
Keywords: patch
removed some cruft from the previous patch file. Also, I noticed that
if I type "about:" i get the correct m18 about page. If i type
"about",  i get the about:plugins page.
oops. forget the part about "about" taking me to the plugins page. It was an
autocomplete thing. It took me to the first item on the list that autocomplete
gave me that matched "about".
a=waterson. you'll probably need to make some build changes, too?
assigning to myself. i'll check in after i've seen that it works on mac and
Assignee: av → endico
It turns out the TypeError I reported earlier for all about: pages, happens when
mozilla loads any page.

To build, grab these files and apply the patch.
08/05/00 01:05  mozilla/netwerk/protocol/about/src/nsAboutPlugins.cpp
08/05/00 01:06  mozilla/netwerk/protocol/about/src/nsAboutPlugins.h
08/05/00 01:46  plugin patch version 2
08/06/00 15:50  mozilla/xpfe/global/resources/content/plugins.html
Works on Win2k.  The patch should be updated to include changes
where appropriate.
Should this be in global, communicator, or navigator? In content or locale?
i'm not sure what you mean. i gave the full path for each
of the files. was that unclear or do you disagree on where
i put the html file? Its in the same directory as the
about:mozilla file.
yes, you said "xpfe/global/resources/content/plugins.html", but I'm not sure,
this is the right location. "content" is not localizable, but the page contains
(english) text. Do you want French users to read that English page? If yes, why?
Ok then. whatever. Do whatever's right.

However i'd like to point out that this file isn't just text. When
javascript in one version of the file is updated all the other versions
will have to be updated as well. Maybe that's just something that 
localizers have to deal with. Are there other html files in locale
directories? If you're not sure what to do i'd ask on the l10n group.

If its going to take a while to figure out how to make it localizable
could you try and get this in the way it is and fix it later so this will
be in for beta since the deadline is coming up soon.
Can we pull the localizable strings out into a dtd or a string bundle?  Isn't 
that SOP?

what is "SOP"?

I don't know off-hand a method to move the localizable parts out.
- DTD in HTML?
- document.write in XUL?
- Never used string bundles.
Nothing unsolveable, but I don't know, if that is worth the hassle.
benb: SOP = Standard operating procedure
brendan: the stuff that needs to be localized is in an html file.

I suppose this could be translated to XML (XHTML) and then the strings
could be handled the normal way. Is there an example of this anywhere?
Aren't we in a hurry to get this in for the branch? It would suck if
this didn't get into netscape6. worse is better.
> Is there an example of this anywhere?

I don't know of any.

> It would suck if this didn't get into netscape6.

Agreed. We have a redirector <about:credits>, so the actual filename doesn't
matter that much. If individual translations skip this file, it would still be
better than not having the feature at all (or not allowing a translation at all).

Another question: Should I hook this up in the UI? Where? In the Help menu (like
4.x) or in the <about:> file? (Of course, this question is no checkin stopper
for the other stuff.)

It looks like the above directory may be the correct place to put this.
That's where about.html lives so it looks like we don't have to xmlify
it. Maybe credits.html should go there too.

Just back from vacation...

Couple of questions/comments I have:

  1. Is this a static page or assembled from a template on the fly? I suspect
     it is the latter since users can download and install plugins at will.
     If so, this template should be localizable.
  2. The content of the "about:plugins" page (in HTML) seems to come from
     each plugin installation. If they are not localizable, it might be hard
     to localize this page: we might end up with a localizable frame but 
     non-localizable individual content. But, I think this is acceptable since
     the directory structure of plugins in Mozilla are not locale-sensitive

I will look into this more...
The page is built with javascript so everything should be in there. I think
the only thing that would be un-localizable is the plugin's description. for
example  "Shockwave Flash 4.0 r12", "FutureSplash Player". I guess that would
depend on whether the user had localized plugins.

Maybe the strings should all be pulled out into js variables and put at the
top of the file to make it easier for localizers.
You're right about the plugin names; the table headers and words like "Filename" 
are localized in 4.x and those are the strings that need to be externalized.
Hi, Dawn:

Please put "plugins.html" in mozilla/xpfe/global/resources/content/
but externalize all localizable strings into


and use stringBundle to retrieve them on the fly.

Depends on: 53493
Why dependency on bug 53493? Worked fine for me.

Again: I think, we can live with the HTML file in locale/, especially if the
alternative is not to have it at all. Because I won't make the change to string
bundles (on time), and I don't know if Dawn can/wants/will.
tao and I tried last night to use string bundles in the html file but discovered
that its not allowed from html. Converting the file to xul wasn't a no-brainer
so we gave up and the plan now is to just check in the original english-only 
html file. scc is in the process of reviewing this again and will probably
check it in.

tao had to change nsNetModule.cpp because of the recent progid overhaul. The
diff in his attachment should replace the diff in my 08/05/00 01:46 attachment.

When this bug is fixed we should open a new bug to make about:plugins
localizable. rginda should be cc'd on that because I believe he's written
a components viewer which might be a good thing to combine with plugins
info. If so, then that would make mstolz's bug 53493 unnecessary since that
would be xul based.
HI, Dawn:

If it is not feasible to convert plugins.html to XUL (and stringbundle)
in time for PR3, could we at least use separate out the localizable strings 
from the rest of the HTML tags. In other words, define localizable strings 
as "JS var" and concatenate them with the rest of the output strings. 
With this, localizers can easily identify what to be localize. It is also 
easier for future conversion. In this case, please place pluginshtml in locale

A comment about the anticipated stability of this code. The code is composed
of two parts:

1) The code that implements the about protocol. This is a modified version
of the about:mozilla code. about:mozilla works so this should too.

2) the plugins.html which actually generates the plugins info via javascript.
I copied this from the old mozilla classic tree and as far as I know its the
same code that's been used in earlier netscape versions and is tested by time.

If this goes in before the branch I think we should avoid risk and just 
check in the old fasioned version for now. I'm confident of this code.
I wouldn't be confident enough of a changed version to check it in before
the branch where causing breakage would be a very bad thing. I don't even
have my own tree any more to test with.
I don't know how bugs in a non-critical html file could break the tree. I made
the file localizable as suggested, by moving the locale-dependant strings to the
top of the source.

I also commented out the filename output, because we don't seem to have enough
rights to get this info - it is blank for me (Linux) all the time.

Attached. Please r=.
Somebody please verify/deny that we don't have sufficent rights to read the
filename (so I can remove the "I think" from the source, which the user can see
via "Page Source" ;) ).

Oh, and remove "index.html" (yuk) from the URL.
I was talking about the risk of the feature being broken. I'm afraid of
last minute "Oh, this won't hurt anything" changes. Famous last words.
Remember that the netscape 6 branch deadline is coming up and we have
one chance to get it right.

Of course, i wont' be checking this in. If the person who does it less
paranoid than me then fine.
Dawn, I would feel OK with checkin in my latest version, but I leave it up to
you. You get the relevant powers to OK, and I can check it in.
the old fasioned version of about:plugins was checked in last night so the
most stable version could get into the branch. After the branch could  you
check in your version ben? Reassigning to BenB.

I understand that rginda did a component viewer a while ago. Maybe in the
long term about:plugins should be combined witht that. Could you talk to  him
about it and see if this makes sense and if so open a bug on it and let mitch
know we dont need bug 53493? If not, open a bug to redo about:plugins with
string bundles and move the 53493 dependencyy to it. If one of these changes
seems like it will happen soon (before any big releases) then maybe the above
change I mentioned  should be skipped and this bug closed. (whichever is less

I'll be away for the next week or so.
Assignee: endico → mozilla
Dawn, it wasn't an optimal solution anyway. Considering the checkin
requirements, for me, it isn't worth the hassle. IMO we should just wait for
rginda's XUL file.

-> endico. I suggest to mark it fixed.
Assignee: mozilla → endico
No longer depends on: 53493
marking this bug fixed. Opened bug 56863 for the issue of
localizing about:plugins.
Closed: 24 years ago
Resolution: --- → FIXED
verified that "about:plugins" works on all branch builds 
(win,mac,linux).Adding : vtrunk to get verified on trunk builds.
Keywords: vtrunk
Verified Fixed on Mozilla trunk builds
linux 102308 RedHat 6.2
win32 102304 NT 4
mac 102312 Mac OS9
Setting bug to Verified and removing vtrunk keyword
Keywords: vtrunk
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.