I see this on Macintosh builds. I'm not sure about other platforms. When I go into my preferences for the Cache, I see garbage for my "Disk Cache Folder" edit field (another bug). When I select that garbage and delete it (and then click OK to my prefs dialog), doing any subsequent browsing causes 32 folders to be created next to the application: 00, 01, 02, 03, ... 0f, 10, 11, 12, 13, ... 1f This is very confusing and disorienting to have so many folders created next to the application. We need to fix this before we ship nsbeta2. here is the line from the prefs file: user_pref("browser.cache.directory", "");

add nsbeta2 keyword; we shouldn't generate all these empty folders (sometimes they are files?!); every browse generates them (no matter how many times you discard them).

Putting on [nsbeta2-] radar. Not critical to beta2.

[hopefully a little clearer this time...] Steps to reproduce this bug: * go into Preference dialog, open the Advanced | Cache preference panel * select the text in the disk cache folder edit field (note: on Mac, this string begins as: AAAAAADsAAIAAQVRdWVzdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC1gERkQkQAAAAAWVQFQ2FjaGUAAAAA. .. (sorry; it's actually much longer than that) * press the delete key so that no text remains in the edit field. * dismiss the preference panel * browse to any page (or load mail with the default page set) Notice that a bunch of folders (sometimes these are files/not folders) are created next to the mozilla/Netscape application. Deleting these folders/files doesn't help since they keep coming back. Users will see these files/folders each time the run the application. In fact, it's now even more difficult to find the executable since more than half of the icons in that folder are created by this bug (and are empty/useless). Possible fixes for nsbeta2 include: * not creating the files/folders next to the application (how about in the users' folder or in Temporary Items or ???) or not creating them at all * create a cache folder in some default location when it's not set * not letting users edit the editfield directly (in 4.x, this wasn't an editable area on Macintosh) [PDT NOTE: the above suggestion should be pretty easy to fix] * remove the edit field from the pref panel altogether

In the case of the disk cache, the problematic code is in nsNetDiskCache.cpp (around line 224).

Putting on [nsbeta2-] radar. Not critical to beta2. Adding "relnote" keyword for PR2 release.

This bug is no longer valid, since we have disabled the feature for the user to select the cache directory. bug 45394 Neeti

-relnote

REOPEN: this was fixed, not invalid.

RESOLVED/fixed

mass remove verifyme requests greater than 4 months old