+++ This bug was initially created as a clone of Bug #284011 +++

*** I've  s/firefox/thunderbird/ on the inital report

Description of problem:
thunderbird often takes an unacceptable length of time (>60 seconds) to start for users in our lab of Fedora 10 machines.

How reproducible:
Always reproducible. Although the steps may seem contrived, they create a
condition which is frequently encountered in day-to-day use of our lab (see
notes below)

Steps to Reproduce:
1. # touch //usr/lib/thunderbird-2.0.0.19/extensions/langpack*
2. $ thunderbird
  
Actual results:
Nothing happens... then 70 seconds later a thunderbird window appears :-/

Expected results:
thunderbird to appear within about 10 seconds of asking


Additional info:
Users' homedirs are mounted over NFS in our setup. 

Rebuilding the extensions cache seems to generate an unnecessarily large number
of writes to files in the profile dir, which I believe is the reason this
operation takes so long.

Rebuilding the cache on startup happens routinely in our setup whenever a user
logs in to a machine other than the last one they used. All the machines are
identically configured, so this really shouldn't be necessary. 

From studying the source of the extension manager and the resulting cache files
I notice that the metric which causes thunderbird to rebuild the extensions cache is the mtime of the directory containing the extension. Whilst the files inside the directories have identical mtimes (having been installed from the same RPM), the same directory on different machines always has differing mtimes, depending only on when the RPM was installed.

Cutting down the number of extensions installed (removing all the un-needed
language packs) helps immensely. Fedora's policy of bundling them all in the
same RPM helps us less so.

This problem also affects Thunderbird in exactly the same way.

--- Additional comment from chckens on 2007-09-09 10:31:12 EDT ---

Created an attachment (id=191071)
strace of firefox startup when issue occurs


--- Additional comment from chckens on 2007-10-03 13:13:46 EDT ---

Whilst I don't really have a clue how to trace and profile the Javascript bits
of firefox, I got quite far sticking a few extra debug messages in to
/usr/lib/firefox-2.0.0.5/components/nsExtensionManager.js.

My finding is that _updateManifests() is called 87 times during startup when all
the extensions' mtimes have "changed", with an average time per call of 477ms.
The vast majority of the calls come from _setOp(), so that was 40 seconds spent
mostly re-writing the same data with some temporary state information added.

This could be done a lot more efficiently, and is probably worth taking upstream.

As for preventing this process of rebuilding extensions from occurring so often
in environments such as ours, a few schemes seem possible: altering the logic to
check the mtime of files within an extension directory rather than the directory
itself, which will match up on every machine; setting the mtime of extension
directories in an RPM post-install script; and setting the
extensions.ignoreMTimeChanges preference to true by default.

I believe setting the ignoreMTimeChanges preference has the consequence of
preventing firefox from noticing extensions upgraded by external processes even
in user profile dirs, so I think it is best avoided.

--- Additional comment from mcepl on 2008-02-21 17:35:09 EDT ---

At this point, we're going to only be taking security fixes and major stability
fixes into this release of Fedora.  However, we still want to ensure the bug is
fixed in the next version.  We'd appreciate if you could test Firefox 3,
available at http://www.mozilla.com/en-US/firefox/all-beta.html or now shipping
as the default in Fedora rawhide and provide feedback as to whether it still
exists so we can file a ticket upstream to try to fix it in Firefox 3 before it
is released.

--- Additional comment from mcepl on 2008-02-21 17:36:32 EDT ---

At this point, we're going to only be taking security fixes and major stability
fixes into this release of Fedora.  However, we still want to ensure the bug is
fixed in the next version.  We'd appreciate if you could test Firefox 3,
available at http://www.mozilla.com/en-US/firefox/all-beta.html or now shipping
as the default in Fedora rawhide and provide feedback as to whether it still
exists so we can file a ticket upstream to try to fix it in Firefox 3 before it
is released.

--- Additional comment from chckens on 2008-02-26 21:13:44 EDT ---

(In reply to comment #3)
> We'd appreciate if you could test Firefox 3,

I had a look at testing this under Firefox 3. It's presently not simple to
reproduce, as neither the upstream distribution nor the Fedora rawhide package
include the cornucopia of langpack extensions which bring out the delays.

I believe this is still an issue with Firefox 3 though, as when I tried copying
the langpack extensions from fc8 Firefox (tweaking the install.rdf file to make
them "compatible" with Firefox 3) the delays measured in the case noted in
earlier comments were roughly the same as before. So still a problem, unless the
langpacks aren't expected to be included in the fc9 Firefox package(?)



--- Additional comment from caillon on 2008-02-28 17:12:05 EDT ---

Graham, I'll be adding langpacks back in to FF3 soon in rawhide, however they
should have %lang attributes in the %files list so you should be able to exclude
them by tweaking %_install_langs (I think that's the right one) in your rpmmacros

--- Additional comment from richard.cunningham.ac.uk on 2008-03-14 13:17:29 EDT ---

We have had this problem for sometime with RHEL4 and RHEL5, based on Graham's
comments we found that the
~/.mozilla/firefox/{weird_string}.default/extensions.cache 
file stores the modification times of the
directories in 
/usr/lib/firefox-1.5.0.12/extensions

I wrote a script which fixes the dates to the build date of the rpm. I have run
it on our machines. The startup time when moving to a new machine has been
reduced from over 1 minute before the change to about 5 or 6 seconds after the
change.

Here is the script:

for package in firefox thunderbird
do
        ver=`rpm -q $package`
        ver2=`rpm -q $package --qf '%{NAME}-%{VERSION}'`
        unixtime=`rpm -q --qf "%{BUILDTIME}\n" $package`
        date=`date -d "1970-01-01 UTC $unixtime seconds"`
        for dir in /usr/lib*/$ver2/extensions/*
        do
                touch -d "$date" "$dir"
        done
done

--- Additional comment from steve on 2008-05-13 11:11:53 EDT ---

Couldn't the langpacks be packaged in separate RPMs?  I can't imagine very many
people feel the need to install every language in existence on their workstation...

--- Additional comment from richard.cunningham.ac.uk on 2008-05-13 12:23:42 EDT ---

Though if you work in a university as I do where people attend from many
different countries this is necessary. We have been using the fix I posted for
sometime and this fixes the issue and I think it could be rolled into the RPM
quite easily so I  don't see the need for an alternative fix to this.

--- Additional comment from caillon on 2008-05-13 12:58:09 EDT ---

See comment #7 from me.  Again, you can tell RPM to only install the languages
you want.  If you don't want to install every language, then don't.  All other
packages in the distro (with one exception) ship every language.  Simply tweak
%_install_langs and you don't even have to worry about running scripts such as
the one in comment #8.

--- Additional comment from richard.cunningham.ac.uk on 2008-05-13 13:22:15 EDT ---

If the RPM was modified to actually set the modified dates on the files in
/usr/lib/firefox-1.5.0.12/extensions
then none of this would be necessary, other RPMs seem to do this. I don't see
why anyone should have to do the steps in #7 or #8 (mine) to get this to work
properly so not having this done automatically for people makes it a bug.

We have found that solving this issue has taken a significant amount of time as
it is not clear at first weather it is a file server tuning issue, network or as
in this case a application issue (which we though was by far the least likely).
This would have been avoided if this bug was simply fixed and I don't understand
why there is so much resistance to actually doing so.

There are also similar issues to this in KDE such as this one:
http://bugs.kde.org/show_bug.cgi?id=104681

--- Additional comment from fedora-triage-list on 2008-05-13 23:12:59 EDT ---

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from rollercow on 2009-01-19 07:33:01 EDT ---

This bug is still present in F10, perhaps should be filed against devel?