Closed Bug 199203 Opened 21 years ago Closed 19 years ago

about:plugins doesn't display anything

Categories

(Camino Graveyard :: Plug-ins, defect)

Product:
Camino Graveyard
Component:
Plug-ins
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Camino0.9

People

(Reporter: bugzilla, Assigned: sfraser_bugs)

References

(
URL
)

Details

Attachments

(1 file)

lugins html file that works.
5.24 KB, text/html
Details 
i thought there might already be a bug on this, but i cannot seem to find one.
found using 2003.03.24.07 camino bits on 10.2.4. pls dup as needed; i'm guessing
this is a result of landing camino onto the trunk.

this is not a problem with commercial (nscp) mach-o bits (tested with
2003.03.25.03).

enter about:plugins in the urlbar and hit return. a blank page displays.
This is because we're missing a CSS file. I'm sure we already have a bug on this.
Assignee: peterlubczynski → sfraser
Is it really about a missing CSS file? Shouldn't it just display the page
without correct styling then?

When I load about:plugins, the display fails because of a JavaScript error.
Looking at the source of the page, it uses CSS file
chrome://communicator/skin/plugins.css which works just fine.

Camino outputs this error to console.log:

2003-04-02 22:04:38.136 Camino[1179] JS error: uncaught exception: [Exception...
"Component returned failure code: 0x80570018 (NS_ERROR_XPC_BAD_IID)
[nsIJSCID.getService]"  nsresult: "0x80570018 (NS_ERROR_XPC_BAD_IID)"  location:
"JS frame :: jar:resource:///chrome/embed.jar!/content/communicator/plugins.html
:: <TOP_LEVEL> :: line 30"  data: no]
2003-04-02 22:04:38.723 Camino[1179] JS error: pluginsbundle has no properties

I used an April 1st (or 2nd) build which seems to be lacking the build ID in the
About box.
So maybe it's missing a string bundle or the XPT file for string bundle APIs.
The page has:

  var strBundleService =
Components.classes["@mozilla.org/intl/stringbundle;1"].getService(Components.interfaces.nsIStringBundleService);
  var pluginsbundle =
strBundleService.createBundle("chrome://communicator/locale/plugins.properties");
  var regionbundle =
strBundleService.createBundle("chrome://communicator-region/locale/region.properties");


chrome://communicator/locale/plugins.properties displays an empty page and
chrome://communicator-region/locale/region.properties gives a "file cannot be
found" error. Both of them, as well as about:plugins page, work fine in Mozilla
1.4a.
*** Bug 202714 has been marked as a duplicate of this bug. ***
URL: about:plugins
looks like you need those two strings bundle files for Camino...
With respect to chrome://communicator/locale/plugins.properties,
I believe that this file is correctly archived into en-US.jar in
the xpfe module, but I am not certain that from there it is incorporated
into any .jar file that makes up part of the Camino bundle
I will try again.

I can't be certain of all my facts, but checking with some archived
copies of Camino/Chimera shows that <URL: about:plugins > worked on the
6th March 2003, but not on the 8th march 2003. This is arguably a 
regression.

I think that there was a reorganisation of which jars various files
in the present case the locale files were placed, and I suspect that
the relevant locale files fell through a crack.

I have tried to identify the files concerned and their new locations,
especially by comparing with Phoenix/Firebird, but this was not as simple as it
looked. It would be worthwhile for whoever made the commits at that
time to either jog his/her memory and put in a fix, or let us have some
hints. I am sure that it is a simple change to manifest or chrome files
that is required, but I have got bogged down whilst trying to uncompress
the required files (which are generated in the build process but not used)
and to put them, loose, into some directory to get things started, prior
to working on the jars themselves.

On the same tack, is there a preferred visual tool on Mac OS X for
examining the contents of a jar or xpi?
I belivie the files introduced / moved by bug 56863 may be the issue, though
plugins.html needs another file which was introduced by bug 131477.

So, for a working about:plugins, you need the following files:
mozilla/xpfe/communicator/resources/content/plugins.html
mozilla/themes/modern/communicator/plugins.css
mozilla/themes/classic/communicator/plugins.css
mozilla/xpfe/communicator/resources/locale/en-US/plugins.properties
mozilla/xpfe/communicator/resources/locale/en-US/region.properties

(actually, you only need one of the CSS files, depends on the used theme)
actually, it seems all the additional files are still missing from embed.jar in
all embed builds, I'm trying to fix this with my latest patch on bug 131477
Blocks: 166966
That is most helpful.

Note that the first line added by you is a duplicate of the one three lines
below.

After inserting your changes, I still get a blank page for "about:plugins",
and this logged message:

JavaScript error: 
 line 0: uncaught exception: [Exception... "Component returned failure code:
0x80570018 (NS_ERROR_XPC_BAD_IID) [nsIJSCID.getService]"  nsresult: "0x80570018
(NS_ERROR_XPC_BAD_IID)"  location: "JS frame ::
jar:resource:///chrome/embed.jar!/content/communicator/plugins.html ::
<TOP_LEVEL> :: line 30"  data: no]

CSSLoaderImpl::LoadSheet URI is "chrome://communicator/skin/plugins.css"
2003-08-08 14:14:40.584 Camino[2989] JS error: uncaught exception: [Exception...
"Component returned failure code: 0x80570018 (NS_ERROR_XPC_BAD_IID)
[nsIJSCID.getService]"  nsresult: "0x80570018 (NS_ERROR_XPC_BAD_IID)"  location:
"JS frame :: jar:resource:///chrome/embed.jar!/content/communicator/plugins.html
:: <TOP_LEVEL> :: line 30"  data: no]
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)
nsLocalFile::Exists path
"/Volumes/Ben/mozilla/chimera/camino/build/Camino.app/Contents/MacOS/plugins"
does not exist
JavaScript error: 
jar:resource:///chrome/embed.jar!/content/communicator/plugins.html line 55:
pluginsbundle has no properties

Line 30 of the html file is:

  var strBundleService =
Components.classes["@mozilla.org/intl/stringbundle;1"].getService(Components.interfaces.nsIStringBundleService);

so we might need to look at nsIStringBundleService, or it could be that there
is some mismatch concerning the path 'chrome://communicator/skin/plugins.css'

Grateful for any further commemts.
CSSLoaderImpl::LoadSheet URI is "chrome://communicator/skin/plugins.css"
does not look like an error to me, it just states that it's using the style
sheet, right?

The problem might be the stringbundle thing...
Does embedded have support of nsIStringBundleService at all?
The message is from this line of code which I added to 'nsCSSLoader.cpp'
  fprintf( stderr, "CSSLoaderImpl::LoadSheet URI is \"%s\"\n", casSpec.get( ) );
at the start of the LoadSheet function.

Actually there are some good log statements in this file, but it  is fearfully
difficult to turn logging on and off on Mac OS X.

What you  say is most helpful & I  will look at the nsIStringBundleService
component.
OK - to get things moving forward here, you'll also need to include intl.xpt
into your build.  

On the Files tree dialog in Project Builder - look at Chimera->Gecko
Components->XPT Files.  Add the file "intl.xpt" which is in
mozilla/dist/Embed/components.

On the Targets tab - for Camino & CaminoStatic, make sure intl.xpt is getting
copied into Executables/components.

Once you do THAT and build (and assuming you have the patch to embed-jar.mn in
bug 131477), the about:plugin window starts to display but dies at the "Find
more plugins here:".

The problem is embed-jar is not including a "regions.properties" file, as
mentioned in that bug.  Even if I manually include it (placing it in
locales/US/communicator-region/" AND include the appropriate contents.rdf file
(at least I think it's appropriate), things still didn't work.

What DID work was editing the plugins.html file, line 32, so that it looked like
this:

var regionbundle =
strBundleService.createBundle("chrome://communicator/locale/region.properties");

and manually sticking the region.properties file in local/en-US/communicator.

I hope somebody else can figure out how to either set up the contents.rdf file
to report its region correctly or set the embed.jar up so I don't have to do
this manually in the future.  
Yes.

I think that I can do the same. I have added the intl.xpt file to the build,
and about:plugins now display:

        Installed plug-ins
        Find more information about browser plug-ins at 

These error messages are logged:

2003-12-21 23:08:31.405 Camino[14973] JS error: uncaught exception:
[Exception... "Component returned failure code: 0x80520012
(NS_ERROR_FILE_NOT_FOUND) [nsIStringBundle.GetStringFromName]"  nsresult:
"0x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame ::
jar:resource:///chrome/embed.jar!/content/communicator/plugins.html ::
<TOP_LEVEL> :: line 61"  data: no]

Lines 59-61 of plugins.html are:

  document.writeln("<div id=\"findmore\">" +
pluginsbundle.GetStringFromName("findmore_label") + " ");
  document.writeln("<a href=\"" +
regionbundle.GetStringFromName("more_plugins_url") + "\">" +
regionbundle.GetStringFromName("more_plugins_label") + "<\/a>.");
  document.writeln("<\/div>");

which tends to put 'regionbundle' firmly in the spotlight. This variable is
initialised on line 32:

  var regionbundle =
strBundleService.createBundle("chrome://communicator-region/locale/region.properties");

I know nothing about communicator-region.

Comparison with the contents of embed-jar.mn around line 35 might be instructive,
or might be a red herring.

Both Firebird and Plain Mozilla can display this plugins.html file with 
'communicator-region'
I am still having a lot of problems with this.

I have looked at the build system for embed.jar and forced 

    locale/en-US/communicator-region/contents.rdf
    locale/en-US/communicator-region/region.properties

into that file. As comment #14, about:plugins does not work, and I have
found that the NS_ERROR_FAILURE is being generated by GetStringFromName( )
<URL
http://lxr.mozilla.org/seamonkey/source/intl/strres/src/nsStringBundle.cpp#182 >
which cannot find a string for the key 'title_label'. I think, but I cannot
be sure, that it is because such a string was never put into the DS hash by
SetStringProperty( )
<URL:
http://lxr.mozilla.org/seamonkey/source/xpcom/ds/nsPersistentProperties.cpp#264 >

It would seem to me that our efforts will be in vain unless we can establish
where in the sources is the code that Camino should be using to read the 
"communicator-region" strings from embed.jar.

It is beginning to look as though ALL the strings are read in at application
launch and then retrieved through a hash.

Again, grateful for any help.

The following things are also needed.
    content/communicator-region/contents.rdf


And, It checks whether the following things are contained in installed-chrome.txt
　　locale,install,url,jar:resource:/chrome/embed.jar!/locale/US/communicator-
region/
    content,install,url,jar:resource:/chrome/embed.jar!/content/communicator-region/

Can we just back out the original about:plugins prettification that caused this?
Assignee: sfraser → pinkerton
sfraser:
I'd vote for forking plugins.html between embed and the rest... That would give
embed an ugly, non-localized, but working plgins.html, while the rest of the
world could still have one that is doing it The Right Way (tm).
(BTW, it wasn't the "prettification" that really screwed up embed, it was the
localization changes, as it looks to me.)

And plugins.html is living in communicator, so either we correctly have this
file and the skin and L10n resources for it in the jars, or we either move it to
some other chrome component where we have skin and L10n resources available or
we use a diofferent implementation for embed that can live without those resources.
3 possible ways to go, none of which should cause a regression in Seamonkey as
your suggestion would.
Target Milestone: --- → Camino0.9
plugins.html seems to have just been moved to global again by firefox ditator
ben goodger. if the proble still persists, reassign the bug to him as he seems
to care what's happening to about:plugins these days.
I hope this bug will be fixed in Camino 0.8f by reason that;
1) Regression. In Camino 0.7 "about:plugins" works fine.
2) In "Camino&#8482; Tips and Tricks"
(http://www.mozilla.org/products/camino/features/tipsTricks.html) "How do I find
out what plugins are available?" is described below;
"Type about:plugins in the Location bar. The page that loads will show you what
plugins are available." 
It stopped working on the 8th March, 2003
i'd say we should fork the plugins file for embedding apps since i'm pretty sure
the MF folks don't really care about them and will break them given any chance
they get.

someone want to take a stab at that?
I've got it figured out; all the breakage is some localization stuff. Take that
out, and it works, and looks exactly the same, except that the formerly dynamic
headers, etc. are all static. We'd just need to decide how we want to do the
localization stuff on our own copy.
Er, by "dynamic" I, of course, mean "localized".
(In reply to comment #24)
> I've got it figured out; all the breakage is some localization stuff.

Yes, it comes down to what comment #3 and comment #9 told - only that it's now
in global instead of communicator.
Attaching the plugins.html file Wevah send me. It works, or at least show all
that is needed. &#10;&#10;Wevah please update this bug with some more
information.
Attachment #172916 - Attachment mime type: text/plain → text/html
(In reply to comment #27)
> Created an attachment (id=172916) [edit]
> plugins html file that works.
> 
WFM. Thank you.

First:
This file won't work in all cases, you'd have to remove the rest of the
pluginsBundle appearances as well.

Second:
This does rip out localization from the file and making it display in US English
only.

Third:
At least we now can be sure the problem is that we somehow don't get the string
bunlde(s), which is good to know. Searching for a correct fix should start
exactly there: Which bundle do we fail to get? One or both? Why?
(In reply to comment #29)
> ...
> 
> Second:
> This does rip out localization from the file and making it display in 
> US English only.

Reading comment 19, this is probably by design and is a stop gap measure
also comment 24.
 
> Third:
> At least we now can be sure the problem is that we somehow don't get 
> the string bundle(s), which is good to know. Searching for a correct 
> fix should start exactly there: Which bundle do we fail to get? One or 
> both? Why?

I made a tentative stab at this in comment 16 (the last sentence of 
comment 16 is not quite correct, but it is broadly true). I don't have 
a Camino build tree at the moment.

This work is appreciated!
May be Off Topic, but one the reasons that this bug ought to be fixed is
so that people can determine what plugins they have, Whilst this is most
important for Flash, it is also very useful for Java problems.

This URL http://www.java.com/en/download/help/testvm.xml gives 
these data and has links to other information about Java.

(Also http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_15507 
for Flash)
Taking.
Assignee: pinkerton → sfraser_bugs
It turns out that we were just missing the intl.xpt file that the plugins.html
needs to do string bundle fu. The requires string bundles are already in
embed.jar. So this was a project change to add intl.xpt.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: