Closed
Bug 249246
Opened 20 years ago
Closed 16 years ago
Installer Icons for FF+TB Cause 100% CPU usage in explorer.exe
Categories
(Firefox :: Installer, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: mozillabugs, Unassigned)
Details
Attachments
(1 file)
13.79 KB,
image/gif
|
Details |
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.
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.
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?
Flags: blocking-aviary1.0PR?
Flags: blocking-aviary1.0?
Comment 5•20 years ago
|
||
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.
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR-
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•20 years ago
|
||
This is likely because of the fact that Firefox now uses a 7-Zip compressed installer, which is slower than Zip to decompress.
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•20 years ago
|
||
Why is this bug unconfirmed? Are we unsure that it's actually a problem?
Reporter | ||
Comment 10•20 years ago
|
||
Yes, it is actually a problem. Still on the latest nightlies. Can someone mark confirmed please?
Comment 11•20 years ago
|
||
NEW -1.0 per bsmedberg
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Updated•19 years ago
|
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Reporter | ||
Comment 12•19 years ago
|
||
This is still happening with Deer Park builds and is horrible to deal with on an older machine. Is this even fixable?
Reporter | ||
Comment 13•19 years ago
|
||
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)
Updated•19 years ago
|
Assignee: bugs → nobody
QA Contact: bugzilla → installer
Comment 14•19 years ago
|
||
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•18 years ago
|
||
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
Reporter | ||
Comment 16•18 years ago
|
||
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•18 years ago
|
||
Can you try right click -> properties on another similar file on that system as well and then compare?
Reporter | ||
Comment 18•18 years ago
|
||
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•18 years ago
|
||
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.
Updated•17 years ago
|
Flags: blocking1.9a1?
Comment 20•16 years ago
|
||
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
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•