36908 - about:plugins does not work

Status: VERIFIED FIXED

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

Description

[Cyril Bortolato]

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:
no]

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

Platform:
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.

Comment 1

[Gervase Markham [:gerv]]

CCing [e-mail], because he seemed to be talking about about: URLS in 
#mozilla today. Tenuous, granted ;-) Still a problem (error appears on console) 
on 20000428, BTW.

Gerv

Comment 2

[Asa Dotzler [:asa]]

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.

Comment 3

[rusty.lynch]

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.

Comment 4

[sean echevarria]

Attachment: html page that iterates thru plugins

Comment 5

[sean echevarria]

Added an html attachment that has the js code used in netscape 4 to produce the 
about:Plugins page.  Works in mozilla.

Comment 6

[Gervase Markham [:gerv]]

Adding nsbeta3 keyword - idea would be to check in the attached HTML file and 
link it up to about:plugins, or something similar.

Gerv

Comment 7

[Sammy Ford]

thanks for the attachment, im working on it now

Comment 8

[Sammy Ford]

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

Comment 9

[sean echevarria]

Adding dependency on http://bugzilla.mozilla.org/show_bug.cgi?id=37504.  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"
or
2) are in the bin/components directory rather than the plugins directory

Comment 10

[sean echevarria]

removing dependency on http://bugzilla.mozilla.org/show_bug.cgi?id=37504
adding dependency on http://bugzilla.mozilla.org/show_bug.cgi?id=44614

Comment 11

[sean echevarria]

The attachment works with xpcom plugins that are registered with the proposed 
solution to http://bugzilla.mozilla.org/show_bug.cgi?id=45698.

Comment 12

[ekrock's old account (dead)]

correctness of support for plug-ins. This info will be invaluable to support at
both Netscape and plug-in vendors when diagnosing problem reports.

Comment 13

[ekrock's old account (dead)]

[nsbeta3-]. Suggested workaround: someone should put up web page on mozilla.org
that uses JS & XPConnect to read registry and display this info.

Comment 14

[Dawn Endico]

Attachment: patch for about:plugins

Comment 15

[Dawn Endico]

Attachment: mozilla/netwerk/protocol/about/src/nsAboutPlugins.cpp

Comment 16

[Dawn Endico]

Attachment: mozilla/netwerk/protocol/about/src/nsAboutPlugins.h

Comment 17

[Dawn Endico]

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"

Comment 18

[Dawn Endico]

Attachment: plugin patch version 2

Comment 19

[Dawn Endico]

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.

Comment 20

[Dawn Endico]

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".

Comment 21

[Chris Waterson]

a=waterson. you'll probably need to make some build changes, too?

Comment 22

[Dawn Endico]

assigning to myself. i'll check in after i've seen that it works on mac and
windows

Comment 23

[Dawn Endico]

Attachment: mozilla/xpfe/global/resources/content/plugins.html

Comment 24

[Dawn 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

Comment 25

[sean echevarria]

Works on Win2k.  The patch should be updated to include makefile.win changes
where appropriate.

Comment 26

[Ben Bucksch (:BenB)]

Should this be in global, communicator, or navigator? In content or locale?

Comment 27

[Dawn Endico]

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.

Comment 28

[Ben Bucksch (:BenB)]

endico,
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?

Comment 29

[Dawn Endico]

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.

Comment 30

[Brendan Eich [:brendan]]

Can we pull the localizable strings out into a dtd or a string bundle?  Isn't 
that SOP?

/be

Comment 31

[Ben Bucksch (:BenB)]

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.

Comment 32

[Dawn Endico]

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.

Comment 33

[Ben Bucksch (:BenB)]

> 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.)

Comment 34

[Dawn Endico]

mozilla/xpfe/global/resources/locale/en-US

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.

Tao?

Comment 35

[tao]

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
     either.

I will look into this more...

Comment 36

[Dawn Endico]

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.

Comment 37

[msanz]

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.

Comment 38

[tao]

Hi, Dawn:

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

  mozilla/xpfe/global/resources/locale/en-US/plugins.properties

and use stringBundle to retrieve them on the fly.

Thanks

Comment 39

[tao]

Attachment: fix compile error: nsNetModule.cpp

Comment 40

[Ben Bucksch (:BenB)]

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.

Comment 41

[Dawn Endico]

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.

Comment 42

[tao]

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
directory. 

thx

Comment 43

[Dawn Endico]

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.

Comment 44

[Ben Bucksch (:BenB)]

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=.

Comment 45

[Ben Bucksch (:BenB)]

Attachment: Make plugins.html a bit more localizable

Comment 46

[Ben Bucksch (:BenB)]

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.

Comment 47

[Dawn Endico]

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.

Comment 48

[Ben Bucksch (:BenB)]

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.

Comment 49

[Dawn Endico]

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
trouble)

I'll be away for the next week or so.

Comment 50

[Ben Bucksch (:BenB)]

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.

Comment 51

[Dawn Endico]

marking this bug fixed. Opened bug 56863 for the issue of
localizing about:plugins.

Comment 52

[shrirang khanzode]

verified that "about:plugins" works on all branch builds 
(win,mac,linux).Adding : vtrunk to get verified on trunk builds.

Comment 53

[Asa Dotzler [:asa]]

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