On 2008-12-05, 13:22 GMT, William L. Maltby wrote:

Got second cup of coffee downed and went to see if the bug was known here https://bugzilla.mozilla.org/buglist.cgi?query_format=specific%5C &order=relevance+desc&bug_status=__open__&content=plugin

Didn't see a match. If someone can confirm, I'll post a bug.

Strange. I am a bug triager of (among others) all gecko-related bugs in the RH bugzilla, and I cannot recall to hear about a bug like this.

Isn't there something strange about your set-up ($HOME on NFS, SELinux issue, ...)?

Best,

Matěj Cepl

On Fri, 2008-12-05 at 10:16 -0500, William L. Maltby wrote:

On Fri, 2008-12-05 at 15:48 +0100, Matej Cepl wrote:

<snip need m ore copy portion>

...

Strange. I am a bug triager of (among others) all gecko-related bugs in the RH bugzilla, and I cannot recall to hear about a bug like this.

Isn't there something strange about your set-up ($HOME on NFS, SELinux issue, ...)?

No NFS active. SELinux would affect all users/apps as far as I can see. No messages in secure or messages related to anything that looks appropriate.

The "something strange about your set-up" was one of my thoughts. AFAIK, it's a "box stock" setup now. However, in the past, I had beta versions of the 3.0.x installed locally. There was some local manual manipulation involved in that. I'll be checking against another login that does not have that history, as a starting point. Subsequent steps will be based on the results of that, e.g. compare directories, permissions, etc. I strongly suspect I'll find something there.

Matěj et al,

I was able to _start_ a comparison process, not completed yet. Details follow. But first, one more piece of background. In response to the previous thread I mentioned, I had saved a copy of the pluginreg.dat as pluginreg.dat-. Did some manual edits, finished trying to help that previous issue and copied the pluginreg.dat- back to pluginreg.dat. All seemed normal at that time, though I can't recall firing up FF by clicking a link from T'bird.

Now, I logged in as a user that had never had the beta version installed and had no prior manual manipulation.

- Made sure that all instances of FF were closed on the system for all users (me, myself and I) - Started T'bird, opened the pertinent mail, clicked the same link - Did cp -a of the pluginreg.dat to pluginreg.dat- (this "duplicates" the structure that exists in the original offending instance). At that version all my stuff seems normal. - Unfortunately, 22 language packs were available. I disabled all those and restarted (btw, when that is done the previous saved tabs are lost - no prompt for "Save ..." is issued - another issue I guess). - Upon restart, there were differences between the pluginreg.dat and pluginreg.dat-. - I repeated the "click on link, cp -a, quit" several times, saving several instances of the pluginreg.dat as -2, -3, ...

Net result is that all plugins but Shockwave Flash disappeared (most other things were still there through -2 version, although a detailed examination will be needed to confirm this) and the _obvious_ and _quickly_ seen changes through version -2 were a re-ordering of the entries and a change to an (apparent) sequence or version number of some kind. After that all disappeared but shockwave.

Doing a "less" on the new pluginreg.dat revealed nothing other than most plugins were gone (mplayer, helix, adobe reader) and many application bindings disappeared.

I also did an "od -c" to see if some hinky DOS formatting crept in. I didn't find any \r\n sequences though, just the normal \n.

I've the saved versions of the pluginreg.dat.

Next-to-last time in FF, I went to tools->add-ons and the plugins tab was empty. I quit and did the "click link" thing again, which started FF again. This time the plugins tab shows Shockwave Flash only is available.

If this is too OT for the list, feel free to mail directly. I'm willing to help any way I can. Further, if there is something else you would like me to try, please just say so.

Thanks for your interest, time and assistance.

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

? And if you have flash-plugin in ~/.mozilla then many bad things will happen to you. Remove it and install the one from Adobe yum repo together with nspluginwrapper from CentOS repos.

Does it help?

Matěj

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.

On Sat, 2008-12-06 at 14:16 +0100, Matej Cepl wrote:

<snip>

Matej,

Last we communicated on this, no resolution yet. I've done all the things you suggested and I now believe a bug in either FF or T'bird.

Thread starts here

http://lists.centos.org/pipermail/centos/2008-December/068837.html

and you last post (which threads to my replies off that one) is here.

http://lists.centos.org/pipermail/centos/2008-December/068898.html

My last query was do you think now there is a bug in either FF or T'bird here

http://lists.centos.org/pipermail/centos/2008-December/068916.html

Other folks chimed in at various points, so you might want to take a gander at those too.

Thanks for your help

On Mon, 22 Dec 2008, Matej Cepl wrote:

On 2008-12-22, 17:58 GMT, William L. Maltby wrote:

...

Other folks chimed in at various points, so you might want to take a gander at those too.

I think I saw couple of these in our bugzilla now and I wonder whether it is the same. Try to run gnome-default-applications-properties and take a look at what's set as your browser application. If it is /usr/lib/firefox*/firefox or something like that, then select the default Firefox and it should work.

Does it help?

I noticed today the same thing. Clicking on links in pidgin no longer worked for since at least a few weeks. When I looked inside pidgin to Configure Browser it brought me to the same dialog with an /opt/firefox*/firefox instead. However I never had an /opt/firefox*.

I might have tested one of Mozilla's binaries in the past, but never in /opt/firefox*/firefox and I certainly did not change it manually.

Is it possible some bug in Mozilla does this automatically when. eg Firefox was set to be the default and then the Mozilla build automatically replaces it with what it thinks is its location (/opt/firefox*) ?

On 2008-12-22, 23:49 GMT, William L. Maltby wrote:

I presume this completes the triage process? Now, who reports

I hope this bug is publicly visible https://bugzilla.redhat.com/show_bug.cgi?id=471193 otherwise just yes, IMHO (and it is not official statement by RH Gecko developers) whole business of Firefox checking being a default browser is unhappy relict of Windows browser wars and it should be eliminated in the Linux FF altogether. I don't know if it happens though.

Matěj

On Mon, 2008-12-22 at 18:49 -0500, William L. Maltby wrote:

SYNOPSIS: Bug between Firefox and

gnome-default-applications-properties

somewhere.

When FF is set to check to see if it is the default browser and it is not and the user selects "Yes" to make it the default, FF writes the full path to the /usr/lib instance in the command and sets the preferred browser to "Custom".

This causes the symptoms that have been seen, including the truncation of pluginreg.dat.

If the user responds "No" when FF asks if it should be the default browser, the settings that were selected in

gnome-default-applications-properties

hold and the adverse symptoms are not seen.

WORKAROUND: tell firefox "No" or to _not_ check to see if it is the default browser after running gnome-default-applications-properties and selecting it there.

CONCLUSION: The gnome-default-applications-properties apparently gets the binary in /usr/bin while FF itself bypasses this binary and goes directly to the /usr/lib/ firefox instance. In this case the adverse symptoms are seen.

Bug somewhere, I presume FF since the

gnome-default-applications-properties

settings work OK and it accesses the binary in /usr/bin.

More detail that you ever wanted to know follows.

<snip>

BTW, I forgot to pull a basic check, so here it is.

$ rpm -qf /usr/lib/firefox-3.0.5/firefox /usr/bin/firefox firefox-3.0.5-1.el5.centos.i386 firefox-3.0.5-1.el5.centos.i386

On Fri, 2008-12-05 at 18:41 -0500, William L. Maltby wrote:

<snip>

Geez Louise!

Went back to the original problem desktop. Did a find plug* -ls in the .mozilla directory. The current pluginreg.dat was 65 bytes. Fired up FF from the desktop, went to T'bird, clicked the link. Went to tools->add-ons and looked at the plugins tab. EVERYTHING IS THERE NOW!

Another find shows pluginreg.dat is now 5267 bytes, the same as my saved pluginreg.dat-.

It's beyond me unless there's the old uninitialized pointer problem, or memory leakage or some-such.

Those files are still available now.

On Sat, 2008-12-06 at 09:56 -0500, "Germán Andrés Pulido F." wrote:

I have seen this exact same behavior under Fedora 9. it seems the bug is with firefox for some reason. It will happens when clicking over a link opens firefox. If firefox is already open, it works OK. I've found no solution yet, other than switching to opera for my browsing needs. I have the tabmixplus extension, I thought it was related. Do you have this extension?

I don't show any extensions at all. I tend to keep relatively "pure" setups.

Regards.

<snip>

On Fri, 2008-12-05 at 08:35 -0500, Phil Schaffner wrote:

William L. Maltby wrote:

...

Fully up-to-date CentOS 5.2 and Firefox browser. A previous thread had a problem with plugins disappearing. I've discovered, by accident, a causal relationship.

Running a Thunderbird mail client (could happen with others? Haven't tested with Evolution yet.) I click a link that opens the browser. BANG! The plugins.dat is "emptied".

Restored from my rsync backup, repeat, BANG! "Empty" again.

Now, if the browser is already open, NP.

<snip>

Bill,

Tried to reproduce this and could not - closed Firefox, clicked on a link in Thunderbird that opens Firefox. All plugins are OK.

Random thought: caused by the link clicked? Try this one for me? Weak possibility, but I thought no use in "ass-u-me"ing.

http://links.seekingalpha.com/links/34878/83/105705/1184

I have no plugins.dat, only

.mozilla/firefox/2ucxmtim.default/pluginreg.dat

Heh. As mentioned in my other post, hadn't had 2nd cup yet. It is indeed pluginreg.dat.

firefox-3.0.4-1.el5.centos thunderbird-2.0.0.18-1.el5.centos

Ditto: T'bird version 2.0.0.18 (20081120)

Have had problems with disappearing plugins when first starting Firefox, and then having them return after closing/restarting. Seemed to be a function of historical user configs and updates as it was not reproducible on a fresh user account. Never could find a bug report on it and did not create one as it worked OK on a clean config. Perhaps you could try this on a fresh account to check out that variable.

Yep. I did go to another account, but it uses evolution. The problem didn't manifest itself using evolution. I'll go to another that uses T'bird and try there. Then, a fresh account.

The fact that I can reproduce it on that account leaves me sure that some kind of bug exists. It may only be exposed by some odd-ball thing in that account or directory structure, like permissions or whatnot.

I'll investigate more throughout the day, as workload permits.

Phil

<snip sig stuff>

Thanks for the reply.