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@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@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
Attachment:
pluginreg.dat.gz
Description: GNU Zip compressed data
Attachment:
rpm_verify.out.gz
Description: GNU Zip compressed data
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
