about:plugins does not work

VERIFIED FIXED

Status

()

P3
normal
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: cyril_bortolato, Assigned: endico)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3-], URL)

Attachments

(8 attachments)

(Reporter)

Description

19 years ago
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.
CCing sford3@swbell.net, 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

19 years ago
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

Comment 3

19 years ago
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

19 years ago
Created attachment 9156 [details]
html page that iterates thru plugins

Comment 5

19 years ago
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.

Gerv
Keywords: nsbeta3

Comment 7

19 years ago
thanks for the attachment, im working on it now

Comment 8

19 years ago
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

19 years ago
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
Depends on: 37504

Comment 10

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

Depends on: 44614
No longer depends on: 37504

Updated

19 years ago
Keywords: 4xp

Comment 11

18 years ago
The attachment works with xpcom plugins that are registered with the proposed 
solution to http://bugzilla.mozilla.org/show_bug.cgi?id=45698.
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 mozilla.org
that uses JS & XPConnect to read registry and display this info.
Whiteboard: [nsbeta3-]
(Assignee)

Comment 14

18 years ago
Created attachment 12411 [details] [diff] [review]
patch for about:plugins
(Assignee)

Comment 15

18 years ago
Created attachment 12412 [details] [diff] [review]
mozilla/netwerk/protocol/about/src/nsAboutPlugins.cpp
(Assignee)

Comment 16

18 years ago
Created attachment 12413 [details] [diff] [review]
mozilla/netwerk/protocol/about/src/nsAboutPlugins.h
(Assignee)

Comment 17

18 years ago
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"
(Assignee)

Updated

18 years ago
Keywords: patch
(Assignee)

Comment 18

18 years ago
Created attachment 12415 [details] [diff] [review]
plugin patch version 2
(Assignee)

Comment 19

18 years ago
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.
(Assignee)

Comment 20

18 years ago
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

18 years ago
a=waterson. you'll probably need to make some build changes, too?
(Assignee)

Comment 22

18 years ago
assigning to myself. i'll check in after i've seen that it works on mac and
windows
Assignee: av → endico
(Assignee)

Comment 23

18 years ago
Created attachment 12460 [details] [diff] [review]
mozilla/xpfe/global/resources/content/plugins.html
(Assignee)

Comment 24

18 years ago
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
Status: NEW → ASSIGNED

Comment 25

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

Comment 26

18 years ago
Should this be in global, communicator, or navigator? In content or locale?
(Assignee)

Comment 27

18 years ago
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

18 years ago
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?
(Assignee)

Comment 29

18 years ago
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?

/be

Comment 31

18 years ago
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.
(Assignee)

Comment 32

18 years ago
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

18 years ago
> 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.)
(Assignee)

Comment 34

18 years ago
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

18 years ago
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...
(Assignee)

Comment 36

18 years ago
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

18 years ago
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

18 years ago
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

18 years ago
Created attachment 15177 [details] [diff] [review]
fix compile error: nsNetModule.cpp

Updated

18 years ago
Depends on: 53493

Comment 40

18 years ago
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.
(Assignee)

Comment 41

18 years ago
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

18 years ago
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
(Assignee)

Comment 43

18 years ago
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

18 years ago
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

18 years ago
Created attachment 15241 [details]
Make plugins.html a bit more localizable

Comment 46

18 years ago
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.
(Assignee)

Comment 47

18 years ago
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

18 years ago
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.
(Assignee)

Comment 49

18 years ago
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.
Assignee: endico → mozilla
Status: ASSIGNED → NEW

Comment 50

18 years ago
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
(Assignee)

Updated

18 years ago
No longer depends on: 53493
(Assignee)

Comment 51

18 years ago
marking this bug fixed. Opened bug 56863 for the issue of
localizing about:plugins.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 52

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

Comment 53

18 years ago
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
Status: RESOLVED → VERIFIED
Keywords: vtrunk
You need to log in before you can comment on or make changes to this bug.