Closed Bug 112508 Opened 23 years ago Closed 23 years ago

about:plugins issues JavaScript error in nsIDOMPlugin

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: serhunt, Assigned: serhunt)

References

Details

Attachments

(4 files)

A screenshot of the plugins not working
80.72 KB, image/jpeg
Details
Screenshot of the working plugins
34.29 KB, image/jpeg
Details
Screen shot of AboutPlugins with only the working plugins installed.
67.25 KB, image/jpeg
Details
patch to fix the problem
772 bytes, patch
dp
: review+
Details | Diff | Splinter Review 
I am filing this bug to consolidate various reports mentioned by different 
people in other bugs (see bug 108246, bug 110011, bug 112097, bug 112313). 

1. go to about:plugins page
2. see it empty or not complete

The problem is hard to reproduce, it may even be invalid after 108246 is fixed 
(post 20011127 builds). It may go away after doing something with the plugin 
directory (like 'touch *' or removing a plugin dll and placing it back). We 
still need a reliable way to reproduce this. I never saw it on my machine.

What I suspect:

1. The problem is caused by just one specific plugin (could be more)
2. This is likely not very well-known plugin (this is my wild guess)
3. This plugin is likely sitting in Netscape 4.x plugins folder (to verify this 
just remove/rename the whole folder temporarily and reissue about:plugins 
command) and therefore
4. This is Windows problem only since we don't do plugin sweep on other 
platforms

Any help in getting this reproducable and/or isolating the problematic plugin 
would be greatly appreciated.
Actually I've gotten this the last few days in Linux. It
seems tied to the Adobe Acrobat nppdf.so plugin there. It's
definitely still appearing in the 2001112903 Windows build
( which also has the Adobe plugin on my system ). I'll try
removing that plugin and see if the problem resolves itself.
If I remove all the NS4 plugins and the Acrobat PDF plugin then
I get an about:plugins page again. The Java plugins aren't listed,
but the page isn't broken. Maybe this is a problem with NS4 plugins
breaking something or being broken internally?
Todd,

You may get some of that page displayed, but did you check the Javascript 
console to see if you got an error that looks like the following?:

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMPlugin.name]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
jar:resource:///chrome/toolkit.jar!/content/global/plugins.html :: <TOP_LEVEL>
:: line 95"  data: no]

If you do see that, then that is exactly the problem.  The only reason you got 
some output is that Mozilla read a couple other plugins that it didn't have a 
problem with, but then ran into some plugin (maybe the Java plugins files) that 
it did have a problem with and, therefore, quit producing anymore output.

Jake
I could see this problem (not anymore) with the pdf plugin too. When it was 
removed and replaced back, things worked again. Is acrobat plugin the problem 
here?
Jake:

I didn't check the console, but one thing. When I get the error it
always results in an incomplete page: text stops at the error and
the page footer isn't there. With just the default plugin and the
Java plugins I got a complete page including the footer. Same thing
in the Linux builds: when I remove the nppdf.so plugin I get a complete
page, with it present I get a page that stops in mid-entry. All the
plugins _work_ right on pages that contain stuff they handle, it's
just about:plugins and the navigator.plugins array that appear to be
broken.

I am experience the same bug you are discribing on the Mac OS 8.6 on the nightly 
from November 29, 2001. I sorted out my plugins into two groups, those which the  
About plugins items to fail with the Javascrip error and those that do not cause 
this Jvavscrip error to be reported. I will include screen shots of the plugins 
that work (i.e. do not create the Javascript error) and those plugins that do not 
work (i.e. these create the Javascript error). I will also post a screenshot of 
the About Plugins screen with the plugins installed that do not show the 
Javascript error.

Another note I have noticed some plugins have failked about the same time I 
noticed the AboutPlugins javascript error. Quicktime is no longer detected as 
installed.

These plugins create the Jvavscrip error and prevent any information from being
displayed in the AboutPlugins.
These plugins do not create the AboutPlugins Javascript error.
Odd addendum. I've got these plugins installed on Linux:

Sun Java from the 1.3.1_01 JDK
Shockwave
Plugger
Adobe Acrobat PDF

When running as a normal user I get just the "Inetalled plugins" header
and then nothing more, and the uncaught exception error. When running as
root, though, I get a complete list of plugins with no errors.
*** Bug 113057 has been marked as a duplicate of this bug. ***
I'm on Win2K, Build 2001120303, and I *always* see the exception come up in the
JavaScript Console, even when the plugins folder is empty, or contains only
npnul32.dll. (same exception as Addition Comment #3).

When it contains npnul32.dll, about:plugins shows the data for that plugin, but
the exception is still thrown.

For some reason, the Java plugins (NPJava11.dll, NPJava12.dll, NPJava131.dll,
NPJava32.dll) aren't displayed, but still allow the default plugin to be
displayed. The exception is still thrown. All other windows plugins I've tried
cause no info to be displayed, and the exception is thrown.

And not all plugins work. Quicktime, and Flash both fail now. Acrobat knows that
it should load, and I see the splash page, but then it just hangs, and the
controls are never shown, the document isn't shown either. eventually, after
nothing happens for a long time, I just close that window. everything continues.

I don't have any Netscape stuff on this system, so if it's a swept plugins
problem, there's something seriously wrong with the sweeper.

Zac.
Request to all who see the problem and has 'touch' utility on the system. Please 
try 'touch *.*' in both Mozilla and Netscape 4.x plugin folders and reissue 
about:plugins.

Is anybody seeing the problem on NT40?
okay, when I touch everything in the plugin dir, the about:plugins page now works. 

But as I mentioned before some plugsin (Acrobat, Quicktime, Flash) now load, but
don't display content. Is that behavior part of this bug?

I did a " touch * " and everything started working normally
I think it could be the application registry. Anyone who is seeing this, be sure
you have an updated build and try deleteing the application registry: 

Linux: ~/.mozilla/appreg

Windows:
Simple: search for registry.dat
Direct: Start, Run, %USERPROFILE%\Application Data\Mozilla
Windows NT sets the userprofile environement. Dunno what Win98 does. On XP on my
machine, it's was here:
C:\Documents and Settings\peterlubczynski\Application Data\Mozilla
Please report back.

==================================
What's going on is that we store/cache plugin information in this application
registry.  As you can see, it's not with the normal build and so it may not get
rebuilt. You can run "regexport.exe" to look at the contents. You should see all
the plugins that Mozilla can possibly find on your system listed. If you still
have a problem, please attach this section to the bug. The ONLY time this
information is updated is when the filestamp of a plugin changes. That may
explain why "touching" may solve the problem.
dp, looks like the plugin info caching code should be more agressive when 
deciding on when to completely refresh the registry. Any suggestions? Looks like 
when we changed couple of entries to be bytes rather than strings and people 
upgraded, the old entries are still used screwing everything up.
Did we bump version number of pluing info when we changed over to bytes ? (I
dont remember). nsPluginHostImpl::kPluginInfoVersion  - looks like we didn't.

// Version of cached plugin info
// 0.01 first implementation
// 0.02 added caching of CanUnload to fix bug 105935
static const char *kPluginInfoVersion = "0.02";

If we bump it, then on next start, the cached plugin info will be thrown away
and reregistration of all plugins initiated.
Once this was fixed for me(replacing/renaming nppdf.dll), I can never reproduce 
it again(1105 winNt)
Please review and superreview.
Comment on attachment 60522 [details] [diff] [review]
patch to fix the problem

r=dp

I think you can go in without sr= This is a one line change of a constant
Attachment #60522 - Flags: review+
For those who still see the problem. If possible, please don't do anything to 
your Mozilla profile files and plugins folders (both Mozilla and 4.x) like 
moving stuff around or 'touching'. Your configuration will be useful for 
verification purposes after I check this fix in.

Srirang, you can try to reproduce the problem doing the following:
- install pre-11.26 build, create new profile, run it, registry entry for 
plugins using string interface will be created
- then install post-11.26 build run with the same profile, luckily you may see 
the problem because this build will expect registry entries created with bytes 
rather that string interface. If so...
- then install whatever build will have the above fix and verify that the 
problem goes away. Or does not :(
Checked in. Please try. Marking fixed. Feel free to reopen.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Blocks: 113285
Thanks for checking this in, this seems to have fixed the problem for me!
(Windows 98 SE, Build 2001120603)
Andrei, I tried what you mentioned.Confirmed/verified-fixed on 1206 trunk on 
WinNT. Marking as such
Status: RESOLVED → VERIFIED
*** Bug 115550 has been marked as a duplicate of this bug. ***
*** Bug 116014 has been marked as a duplicate of this bug. ***
*** Bug 116735 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: