249246 - Installer Icons for FF+TB Cause 100% CPU usage in explorer.exe

Status: RESOLVED WONTFIX

(Firefox :: Installer, defect)

Description

[jsnod]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1

Something seems to be wrong with the FF and TB Installer Icons
(FirefoxSetup-0.9.exe and ThunderbirdSetup-0.7.exe, as well as the .1 releases).

When browsing to a network share folder containing these files, the default
windows application icon is shown (rather than the neater-looking installer
icon).  CPU usage in explorer.exe shoots up to 100% for several minutes until
the installer icons get properly generated/displayed.  Once the icons are cached
by windows, this doesn't happen anymore (use TweakUI to clear Windows icon cache
to see this bug).

Interestingly, this does not happen when the files are contained in local
folders.  It only happens when they are contained in a network shared folder.

The icons display fine for FirefoxSetup-0.8.exe and the moailla*.exe series.

I have seen this on 2 seperate machines, on 2 seperate networks, on 2 seperate
OSs (WinXP & Win2k), so it's not something on my configuration.

This is a big problem for people such as myself who are trying to deploy FF+TB
in a corporate environment by installing the apps on multiple systems from a
network share.

Reproducible: Always
Steps to Reproduce:
1. Create a folder on another machine in your network and share it.
2. Place FirefoxSetup-0.9.exe and/or ThunderbirdSetup-0.7.1.exe in the network
share.
3. From a different machine, browse to the shared folder containing those files
using Windows Explorer

Actual Results:  
CPU shoots to 100% for several minutes, installer application icons are not
displayed.

Expected Results:  
Installer application icons should be displayed immediately.  CPU should not
shoot to 100%

Screencap coming.

Comment 1

[jsnod]

Attachment: Screencap showing broken icons.

Comment 2

[jsnod]

Furthermore, get the properties of the installer by Right-Clicking and choosing
Properties, and notice how long it takes to display the Properties dialog.  On
my home machine (p4 1.8Ghz) it spikes to 100% for 5 seconds before displaying
the dialog.  Doing the same on FirefoxSetup-0.8.exe brings up the Properties
dialog instantly with no CPU spike.

I retract my statement about it having to be on a network share - it's happening
on my local drive on my home system.

Comment 3

[Craig Box]

The problem still occurs in Firefox 0.9.3.

Comment 4

[jsnod]

I'd hate to see 1.0 released with this... the perception is that Firefox will
"slow down my system, man" without it even being installed!  Try the installer
on an older below-Ghz machine and it becomes a real problem.

Blocking?

Comment 5

[Wolf [:wolf]]

As this bug is unconfirmed, and 1.0PR is RSN. I don't think this bug should
block the 1.0PR release. I'm leaving the 1.0 nomination, though you really
should try to get a couple more people to comment that they experience this and
have it confirmed.

Comment 6

[Craig Box]

http://www.hs.net.nz/~crb/FirefoxFileAccessLog.zip

I cleared the icon cache with TweakUI and ran NTFileMon (from Sysinternals) to
watch file access on the directory containing the FirefoxSetup.exe.

Mozilla 1.6's installer had 597 accesses in order to draw the icon and move on;
Firefox took 35,236 (60 times more!)

Hopefully this will help debug the problem - I can't find a pattern to machines
suffering from it; I have a Windows XP Home machine that doesn't suffer from it,
and Windows XP Pro machines, domain members and not, that do.  I recall having a
WinXP Pro machine that wasn't on the domain that didn't have the problem but
can't replicate it at the moment.

Comment 7

[Robert Parenton]

This is likely because of the fact that Firefox now uses a 7-Zip compressed
installer, which is slower than Zip to decompress.

Comment 8

[jsnod]

This translates into a pseudo denial of service when browsing to a folder
containing multiple installer EXEs.  I've experienced 100% CPU usage in excess
of 5 minutes.  Try it on a 486, it's not fun.  

Comment 9

[Asa Dotzler [:asa]]

Why is this bug unconfirmed? Are we unsure that it's actually a problem?

Comment 10

[jsnod]

Yes, it is actually a problem.  Still on the latest nightlies.  Can someone mark
confirmed please?

Comment 11

[Peter van der Woude [:Peter6]]

NEW
-1.0

per bsmedberg

Comment 12

[jsnod]

This is still happening with Deer Park builds and is horrible to deal with on an
older machine.  Is this even fixable?

Comment 13

[jsnod]

This also happens when viewing properties of the installer EXE.

To Reproduce:

1) Open up Windows Task Manager
2) Right click > Properties on installer EXE file
3) Watch CPU in Task Manager shoot up to 100% for 2-15 seconds (depending on
your CPU speed)

Comment 14

[Max Waterman]

I also see this problem and it is a big problem for me as I am also trying to
encourage people to use FF&TB in my company - it doesn't look good when it takes
several minutes just to display the icon.

Comment 15

[Robert Strong (they/them - no direct email)]

I believe this is wfm with the new installer that landed - bug 326580. Reporter, could you please confirm with a latest 1.8.1 branch nightly? Thanks.
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8

Comment 16

[jsnod]

It's hard to tell, as I'm no longer on any of the systems that were displaying the problems before.  The icons show up instantly for the latest 1.8.1 branch nightlies, but Right Click > Properties is still a fairly CPU intensive process.  Does anyone have an older system lying around that they can test this with?

Comment 17

[Robert Strong (they/them - no direct email)]

Can you try right click -> properties on another similar file on that system as well and then compare? 

Comment 18

[jsnod]

I tried it on the Apache 2.0 MSI installer and Properties pop up instantly with 0 CPU usage.  Also tried it on the MySQL MSI installer and also the WinSCP EXE installer.  No problems with those either.  So there is still definately a problem with the Firefox installers.

Comment 19

[Robert Strong (they/them - no direct email)]

It is a 7-zip self extracting archive... I bet the OS is just sniffing the file and that there is nothing we can do about this without increasing the installer size which we aren't going to do... though Microsoft or 7-zip may be able to.

Comment 20

[Robert Strong (they/them - no direct email)]

This is the OS sniffing the 7-Zip file and we aren't going to stop using it at this time. This won't be a problem after we implement an MSI installer but even if we didn't we can't fix this except by not using a self extracting archive which we wouldn't stop using just because the OS is causing high CPU usage by sniffing the file.

Resolving -> Wontfix