Bug 116787

Is there a message in Tools->Extensions?

The extension isn't listed in Tools->Extensions at all, so this is a
packaging/installation issue, not a programmatic one.  Reassigning to wolfgang
and CCing gekker.

We didn't change anything.
The rebuild-databases.sh stuff should register the extension globally.
This didn't work for older prereleases if subdomain was running. Maybe this is
still an issue? I'm at Brainshare now and can't test rc2.
Was it an update?
Does it work if you
rpm -e MozillaFirefox MozillaFirefox-translations
rm -rf /opt/MozillaFirefox
rpm -Uhv MozillaFirefox*

Which extensions do you see in /opt/MozillaFirefox/lib/extensions?

Extension is still not in the firefox extension list.  I actually see no
extensions there.  I can add the beagle extension manually and it works.

strange, will investigate

We don't prereq beagle and we don't trigger the rebuild-databases.sh script at
installation of beagle. So if beagle gets installed after MozillaFirefox we
can't register the extension as they isn't there at this time.

Can we just run rebuild-databases.sh in %post of beagle if it exists then?

Waiting on the SWAMP id from aj.

(In reply to comment #7)
> Can we just run rebuild-databases.sh in %post of beagle if it exists then?

yes, if  /opt/MozillaFirefox/bin/rebuild-databases.sh exists it can be called
there. I consider this as temporary workaround not as solution. We have to fix
this in the Firefox package IMHO.

Maintenance-Tracker-2354

Gary, JP, we will hopefully release a security update for Firefox this or next
week. So you don't need to take the change to the beagle package.
https://bugzilla.novell.com/show_bug.cgi?id=117619

Regarding comment #9. I don't consider running rebuild-databases.sh in the 
beagle package a temporary workaround. It's the beagle package that contains 
browser-extensions/firefox/beagle.xpi file, so it should register it with 
firefox. IMHO it makes no sense that the firefox package contains triggers for 
every package that contains an extension, it's much cleaner and simpler to 
call rebuild-databases.sh in those packages. 

Hmm, it would be nice if an extension could register itself easily. But that's
not possible at the moment.
Firefox unregisters all global extensions if firefox -register is running. So we
have to re-install the global extensions (and themes) afterwards again.
A simple call to rebuild-databases.sh is not possible because of that. We have
to know within rebuild-databases.sh which extensions should be installed.
We still end up with two different places for extension registration
(rebuild-databases.sh + the call to execute it). Both is done now in Firefox and
therefore in one place.

OK, we could introduce some extension meta-registration with some magic *.d
stuff but that's not there yet.
As most of the registration stuff is not needed anymore with Firefox 1.5 I don't
want to make big changes to that now.

I don't understand this. Where's the difference between calling 
rebuild-databases.sh from beagle's postinstall script and firefox' trigger 
script? If there's a way to not use trigger scripts you should use it. 

Hmm, I see that the beagle package in 10.0 is missing the rebuild-database.sh 
call. So I fear that we don't have any other way to fix it for 10.0 (besides 
providing a beagle update, which is a bit overkill). 
 
But please change the code in STABLE. Triggers are bad, avoid them if you can. 

Uh, I just saw the bunch of tiggerpostun entries further down in the specfile. 
You can't be serious. Why did that ever get checked in? Sigh. 

We are preparing a beagle update for a couple of other bugs, so we can slide
this in.  We had left it because of Wolfgang's earlier comments.

Wolfgang, will the 1.5 version get rid of both add-plugins.sh and 
rebuild-databases.sh? If yes, we shouldn't touch beagle so that we don't 
have to update it again if 1.5 is out. 
 

I'm not yet sure if we can get rid of both.
But we hopefully have no Firefox update to 1.5 in 10.0 anyway.

We've introduced triggers to get rid of SuSEconfig.mozilla. We can revert this
if SuSEconfig is a better option. I never get any hint that triggers are bad.
At least they work since ages (8.1 IIRC). But I will try for 10.1 to get rid of
many triggers.
(For add-plugins.sh we have some sort of tracking bug in #118172, but we still
need a solution for Java plugins)
The --install-global-{theme,extension} stuff is hopefully fully fixed in 1.5 and
then we can get rid of rebuild-databases.sh as the standard registration stuff
isn't needed anymore.

Alas, I will check in the 10.0 version now, so we can push out the security 
update. 
 
Regarding the triggers: It's bad design that the firefox package must have a 
trigger for every plugin. Really bad design. 

Marking as fixed, since a workaround was added to firefox.