Closed Bug 531492 Opened 15 years ago Closed 4 months ago

Slow startup because of shortcuts to other folders in the %userprofiles\Favorites folder

Categories

(NSS :: Libraries, defect, P5)

x86
Windows XP

Tracking

(Not tracked)

RESOLVED INACTIVE

People

(Reporter: andrewgr40c, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [ts])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.0.11, Ant.com Toolbar 1.3 (.NET CLR 3.5.30729) Creative ZENcast v2.01.01
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.0.11, Ant.com Toolbar 1.3 (.NET CLR 3.5.30729) Creative ZENcast v2.01.01

Problem:  Firefox takes a long time (over a minute to start up).  Problem exists even with a new Firefox profile (no add-ons).

I noticed this problem in both Firefox and SeaMonkey on Windos XP OS.

In Windows Explorer, I have added Favorites to common folders that I browse... My Music, My Photos and network UNC paths. 

When I deleted the shortcuts, Firefox and SeaMonkey startup was normal.



Reproducible: Always

Steps to Reproduce:
1. In windows explorer, add a Favorites shortcut to My Pictures folder
2. In windows explorer, add a Favorites shortcut to My Music folder
3. In windows explorer, add a Favorites shortcut to a very large UNC network path
4.  Start firefox
Actual Results:  
Firefox takes a long time to start up... over a minute on a slow hard drive.

Expected Results:  
Firefox starts up immediately.

Firefox should not follow shortcuts to other directories when scanning the %userprofile% directory on startup.
This seems to be the same issue as bug 501605, the stupid random number thing in NSS.
Assignee: nobody → nobody
Component: General → Libraries
Product: Core → NSS
QA Contact: general → libraries
Matthias, are you sure ? CSIDL_FAVORITES is not used in any part of Gecko. And neither is nsDirectoryService::sFavorites or NS_WIN_FAVORITES_DIR.

Bug 501605 made sure we don't read any more of the temporary files (CSIDL_FAVORITES was never used for that), unless RNG_SystemRNG failed to call SystemFunction036 or CryptAcquireContextA. I don't see why they should both have failed.
I'm not seeing any access to Favorites when I make a log with Precess Monitor.

Andrew : do you see the same behavior when using Firefox in Safe Mode (see <http://support.mozilla.com/en-US/kb/Safe+Mode>) ? That would disable all extensions. Can you also pass a list of your plugins ? Maybe one of them is accessing your Favorites.
No, I'm not sure.
There is no reason to read the favorites folder unless you are doing the initial import of the IE favorites. I only know that the NSS random number generator used windows and IE system files. Sorry if I made a wrong assumption, this could be an addon bug caused by an addon like IETAB.
In safe mode, it takes approximately 17 seconds to start compared with 25 seconds in regular mode.  I do have a lot of extensions, but I did create a new profile and was seeing a similar delay with that profile.

I had a problem with SeaMonkey starting up and closing when I figured the favorites folder might be causing a problem.  I had just installed SeaMonkey and could not start it.  I watched Process Monitor and found that it was trying to access a network, UNC, folder that was in my favorites as a shortcut that no longer existed.  SeaMonkey would fail to start.  I deleted that shortcut and SeaMonkey was able start.  

I figured I should try that with Firefox... cleaning out my favorites folder, and I'm noticing increased start up time for Firefox.  

I had tried all of the other suggestions in the other bug report... they helped a little, but this seems to have helped a lot to increase the start up time.
we import IE bookmarks using the literal "Favs" instead of the define, which hid that usage from the search in comment #2 (filed bug 548614 to fix it).

that's the only other usage i could find in the repo though. maybe there's something triggering IE favorites import at startup?
Whiteboard: [ts]
Blocks: 447581
Whiteboard: [ts] → [ts][Snappy]
this is too stale to pickup for snappy(unless someone can still reproduce this)
Whiteboard: [ts][Snappy] → [ts]
Severity: normal → S3
Severity: S3 → S4
Status: UNCONFIRMED → RESOLVED
Closed: 4 months ago
Priority: -- → P5
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.