[CentOS] [OT] Firefox loses plugins, anyone else? Bug? Known?
William L. Maltby
CentOS4Bill at triad.rr.com
Sun Dec 7 13:42:11 UTC 2008
Same _bad_ behavior occurs on first attempt after doing below! Details
below.
On Sat, 2008-12-06 at 14:58 -0500, William L. Maltby wrote:
> On Sat, 2008-12-06 at 14:16 +0100, Matej Cepl wrote:
> > On 2008-12-05, 23:48 GMT, William L. Maltby wrote:
> > >> I was able to _start_ a comparison process, not completed yet.
> >
> > What is the output of the command
> >
> > mozilla-plugin-config -l
> >
>
> # mozilla-plugin-config -l
> -bash: mozilla-plugin-config: command not found
>
> Hmm... after an updatedb, did this
>
> # locate mozilla-plug
>
> No results.
>
> > ? And if you have flash-plugin in ~/.mozilla then many bad things
>
> Looks like I'm OK there.
>
> $ cd .mozilla;find . -iname '*plug*'
> ./firefox/9be8vroz.default/pluginreg.dat-
> ./firefox/9be8vroz.default/pluginreg.dat-2
> ./firefox/9be8vroz.default/pluginreg.dat
>
> # locate flash-plugin
> /home/hardtolove/Desktop/flash-plugin-9.0.124.0-release.i386.rpm
> /usr/lib/flash-plugin
> /usr/lib/flash-plugin/LICENSE
> /usr/lib/flash-plugin/README
> /usr/lib/flash-plugin/homecleanup
> /usr/lib/flash-plugin/libflashplayer.so
> /usr/lib/flash-plugin/setup
> /usr/share/doc/flash-plugin-10.0.12.36
> /usr/share/doc/flash-plugin-10.0.12.36/readme.txt
>
> This is the one from the adobe site.
>
> # rpm -qv flash-plugin
> flash-plugin-10.0.12.36-release
>
>
> > will happen to you. Remove it and install the one from Adobe yum
> > repo together with nspluginwrapper from CentOS repos.
>
> Did it.
>
> # rpm -q nspluginwrapper
> nspluginwrapper-0.9.91.5-22.el5
>
> However, when I restart FF, this plugin does _not_ appear in the
> tools->add-ons plugins tab window. Should it? The pluginreg.dat seems to
> have been updated and the nspluginwrapper is in there.
>
> ]$ cd .mozilla
> [hardtolove at centos501 .mozilla]$ find . -iname '*plug*' -ls
> 16285943 12 -rw------- 1 hardtolove hardtolove 5267 Nov 20
> 19:55 ./firefox/9be8vroz.default/pluginreg.dat-
> 16288526 8 -rw------- 1 hardtolove hardtolove 65 Dec 5
> 17:37 ./firefox/9be8vroz.default/pluginreg.dat-2
> 16288502 12 -rw------- 1 hardtolove hardtolove 5859 Dec 6
> 14:32 ./firefox/9be8vroz.default/pluginreg.dat
> [hardtolove at centos501 .mozilla]$ date
> Sat Dec 6 14:44:38 EST 2008
>
> $ grep nsplug ./firefox/9be8vroz.default/pluginreg.dat
> /usr/lib/nspluginwrapper/npwrapper.so:$
> <a
> href="http://gwenole.beauchesne.info/projects/nspluginwrapper/">nspluginwrapper</a> is a cross-platform NPAPI plugin viewer, in particular for linux/i386 plugins.<br>This is <b>beta</b> software available under the terms of the GNU General Public License.<br>:$
>
> >
> > Does it help?
>
> Might be hard to tell since the behavior is inconsistent. But everything
> is now set the way "we" think it should be.
>
> >
> > Matěj
>
> Since missing stuff reappeared during testing, I guess there will
> be a delay while I see if the behavior occurs again.
I went to the login that first exhibited the problem (that's the one
that had a beta version locally installed in the past and had been
manually manipulated at various times while I tried to help solve
another's problem with FF plugins).
$ cd .mozilla/firefox/9be8vroz.default
$ cp -a pluginreg.dat pluginreg.dat-3
Started up T'bird: no instances of FF were running on the system.
Clicked a link that opened FF.
$ ls -ltr plug*
-rw------- 1 hardtolove hardtolove 5267 Nov 20 19:55 pluginreg.dat-
-rw------- 1 hardtolove hardtolove 65 Dec 5 17:37 pluginreg.dat-2
-rw------- 1 hardtolove hardtolove 5859 Dec 6 14:32 pluginreg.dat-3
-rw------- 1 hardtolove hardtolove 65 Dec 6 18:07 pluginreg.dat
This was the situation before and after I exited FF. As you can see, the
"-3" version (made with the cp -a) had lots in it. The real file is now
again "empty".
$ cat pluginreg.dat
Generated File. Do not edit.
[HEADER]
Version:0.09:$
[PLUGINS]
Clicked the URL again in T'bird and FF starts up and shows additional
plugins are needed to ... well, you know.
An ls showed everything as above.
I started FF from the desktop and everything magically returns.
$ ls -ltr plug*
-rw------- 1 hardtolove hardtolove 5267 Nov 20 19:55 pluginreg.dat-
-rw------- 1 hardtolove hardtolove 65 Dec 5 17:37 pluginreg.dat-2
-rw------- 1 hardtolove hardtolove 5859 Dec 6 14:32 pluginreg.dat-3
-rw------- 1 hardtolove hardtolove 5859 Dec 6 18:23 pluginreg.dat
A diff of the .dat-3 and .dat shows they are identical.
All this leads me to believe there is something related to firing it up
from T'bird. Environmental variables? The launcher shows "firefox %u". I
examined T'bird's account settings and preferences. Didn't see anything
there that looked like it might be similar to this.
I looked at FF preferences, nothing promising. It does check to see if
it's the default browser on start-up.
The JAVA console shows 8 warnings, but no errors. I'll take another look
at this after a launch from T'bird again.
Testing, testing, ...
Clicked on URL, .dat is 65 bytes again. Error console shows _many_ more
warnings (mostly undefined property zoom, subsequent unexpected
terminators, etc.). I don't know if these are from the T'bird invocation
or the FF invocation. I see that T'bird has an error console. I'll check
to see what I can ascertain. Checking, checking, ...
Starting T'bird produces no messages. Selecting a post produces none.
Clicking a URL produces none (of course, the pluginreg.dat is still
"empty" and the web pages shows plugins are needed).
This leads me to ask "Is it possible that the problems are being caused
by one of the plugins?". I hope I don't need to remove them one-by-one
to find out. JIC, I've compressed and attached the pluginreg.dat-3
(latest copy of a "good" one). Maybe you'll see something that is a
known "bad actor". But, I would think this would occur regardless of
method of invocation, unless that "%u" is a critical thing and is not
passed (AFAICT) when T'bird start up. But so much of this stuff is just
so "magical" that I have no confidence in my guesses.
I exited the FF, started from desktop and all was good again. That's
sort of "magical", huh? Java error console has the 8 warning messages
again.
NOTE: I just realized that the original problem login and the test have
a small sifference. The original problem one has a default startup page
that requires plugins. The "pure" login has a startup page that doesn't
need any plugins.
I clicked a URL in the mail, got the large number of warnings again and
one error: Error: Permission denied to call method Location.toString.
>From my programming background, I wouldn't guess this to be related.
Repeated and rinsed for the other login, which is the one that was
"pure".
Before starting, noted that the pluginreg.dat still had only the
shockwave and futurewave flash entries (left from the previous test).
At a command line, entered "firefox". Got this when I cliked the link in
T'bird.
$ firefox
*** NSPlugin Viewer *** WARNING: unhandled variable 17 in
NPN_GetValue()
*** NSPlugin Viewer *** WARNING: unhandled variable 17 in
NPN_GetValue()
When I close the tab in FF that was opened by the T'bird launch, got
these.
(npviewer.bin:18586): Gtk-CRITICAL **: gtk_style_detach: assertion
`style->attach_count > 0' failed
(npviewer.bin:18586): Gtk-CRITICAL **: gtk_widget_destroy: assertion
`GTK_IS_WIDGET (widget)' failed
and the pluginreg.dat came back to life. Got a message saying there was
a new PDF Download 1.0.11, version 2.0.0.0 is available. I went ahead
and installed it. I saved the new pluginreg.dat as -5. Exited FF.
NOTE: in a subsequent iteration, the pluginreg.dat is _not_
reconstructed upon command line invocation. This one has no page on
startup that needs plugins. When the link in the T'bird message is
clicked, the pluginreg.dat is rebuilt.
I fired up T'bird, selected the test mail, clicked the URL. The site is
not responding now, used the opportunity to see if pluginreg.dat was
still OK. It was. The network got a timeout, pluginreg.dat is still OK.
Exited FF, pluginreg.dat still OK. Will try later.
Eat dinner, watch TV, putz around, ... next A.M. ...
Came back and tried the process again.
After clicking the link, FF loads and I see this again.
$ ls -ltr plug*
-rw------- 1 bill bill 4939 Mar 16 2008 pluginreg.dat-
-rw------- 1 bill bill 5450 Dec 5 17:18 pluginreg.dat-2
-rw------- 1 bill bill 290 Dec 5 17:29 pluginreg.dat-4
-rw------- 1 bill bill 290 Dec 5 17:29 pluginreg.dat-3
-rw------- 1 bill bill 6042 Dec 6 19:14 pluginreg.dat-5
-rw------- 1 bill bill 290 Dec 7 07:16 pluginreg.dat
And pluginreg.dat contains only this.
$ cat pluginreg.dat
Generated File. Do not edit.
[HEADER]
Version:0.09:$
[PLUGINS]
/home/bill/.mozilla/plugins/libflashplayer.so:$
:$
1195590240000:1:5:$
Shockwave Flash 9.0 r115:$
Shockwave Flash:$
2
0:application/x-shockwave-flash:Shockwave Flash:swf:$
1:application/futuresplash:FutureSplash Player:spl:$
I quit FF, started from the desktop.
NOTE: as mentioned the pluginreg.dat is not "reconstructed" until I
click on a URL in the mail message. I.e, the pluginreg.dat is still
-rw------- 1 bill bill 290 Dec 7 07:16 pluginreg.dat
After I click on a link, we have
-rw------- 1 bill bill 6042 Dec 7 07:25 pluginreg.dat
And it has several references to wrappers, including the
nspluginwrapper. This is the same as in the original problem login's
pluginreg.dat. I don't recall that we had mentioned the mozilla stuff
in /usr/lib before, but it's in there too.
$ grep wrapper pluginreg.dat
/usr/lib/nspluginwrapper/npwrapper.so:$
<a
href="http://gwenole.beauchesne.info/projects/nspluginwrapper/">nspluginwrapper</a> is a cross-platform NPAPI plugin viewer, in particular for linux/i386 plugins.<br>This is <b>beta</b> software available under the terms of the GNU General Public License.<br>:$
/usr/lib/mozilla/plugins-wrapped/nswrapper_32_32.nphelix.so:$
/usr/lib/mozilla/plugins-wrapped/nswrapper_32_32.mplayerplug-in.so:$
/usr/lib/mozilla/plugins-wrapped/nswrapper_32_32.mplayerplug-in-wmp.so:$
/usr/lib/mozilla/plugins-wrapped/nswrapper_32_32.mplayerplug-in-dvx.so:$
/usr/lib/mozilla/plugins-wrapped/nswrapper_32_32.libflashplayer.so:$
/usr/lib/mozilla/plugins-wrapped/nswrapper_32_32.nppdf.so:$
/usr/lib/mozilla/plugins-wrapped/nswrapper_32_32.mplayerplug-in-rm.so:$
/usr/lib/mozilla/plugins-wrapped/nswrapper_32_32.mplayerplug-in-qt.so:$
Maybe a clue herein? From the above, we can see that the pluginreg.dat
is not "reconstructed" until a link is clicked (and I guess that FF
would need some plugins for it too). However, the pluginreg.dat is
"destroyed" when FF is launched by T'bird when a link is clicked.
This implies that there is a different process happening when FF is
launched by clicking a link in T'bird that references a web page needing
plugins in FF than the process that occurs when FF is already opened and
that same link is clicked. Note that each time the pluginreg.dat was
"reconstructed automagically", a link referencing a page requiring
additional plugins (i.e. the pluginreg.dat at that time was essentially
"empty") was either clicked (the "pure" test login) or a web page that
needed plugins was the default on startup (the original problem login).
I remind that the desktop invocation (from the toolbar) has the "%u"
parameter. Further, when invoked from the command line, the normal
environmental variables are available - not sure if this is significant
- and we get some GTK-related messages. I could find nothing in T'bird
that looked like any kind of parameter was passed that might affect
things. Maybe I just don't know where to look?
> <snip>
That's all I can think of to do, ATM. OOPS! Almost forgot.
I ran an rpm --verify, as root. I didn't see anything that _I_ could
relate to the problem, but my insight is limited here. I do note that
some errors have crept in over time that I will now need to pursue.
<*sigh*> The downside of having a reliable platform is that one tends to
not keep a watchful eye open for problems.
That prompts a big "THANK YOU" to all the CentOS team and users that
help make CentOS what it is.
Matěj: I suspect that we have now progressed to the point that this is
certainly a reportable bug? Unless you see something in the rpm verify
output (attached) or suspect something in the CentOS setup (or my
setup), we have progressed too _way_ OT for the CentOS list?
Thanks for your help on this. If there's anything else you want me to
do, a post privately is acceptable to me _if_ we have indeed become OT.
Is it bugzilla time yet?
Thanks again for your help and when this is solved, I will post a
[SOLVED] message.
--
Bill
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pluginreg.dat.gz
Type: application/x-gzip
Size: 98 bytes
Desc: not available
URL: <http://lists.centos.org/pipermail/centos/attachments/20081207/0ea2de7b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rpm_verify.out.gz
Type: application/x-gzip
Size: 1352 bytes
Desc: not available
URL: <http://lists.centos.org/pipermail/centos/attachments/20081207/0ea2de7b/attachment-0001.bin>
More information about the CentOS
mailing list