While trying to analyze a bug in the Firefox Download Manager (bug 291369) I've bumped into another bug. Just as I said in bug 291369 comment #6, it seems that moz-icon://FILE_PATH?size=32 is generated when you just start download an application (windows only), and then it is supposed to change to the PE file's icon, but there's a hack in place in order for this to work: http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/downloads/content/downloads.js#135 Trying to access moz-icon://FILE_PATH?size=32 after the file has been downloaded will still give you the generic application icon, because it has been cached. And even though the toolkit/mozapps/downlodas/content/downloads.xml defines that icon with the validate="always" property, it still gets cached. If this issue is fixed then the "hack" in downloads.js can be removed and disappearing exe icons will be a thing of the past on win32.
The caching stuff applies to HTTP only. -moz-icon: doesn't define a way to validate it, so it's assumed to always be valid. Oh, and -moz-icon: doesn't use our cache either. So should imagelib just always bypass its cache for VALIDATE_ALWAYS on non-http URIs?
It would be helpful if someone could step through imgLoader::ValidateEntry for one of these -moz-icons and tell me whether request->mLoadId is equal to key, and if not, what ShouldRevalidateEntry returns. From my reading of the code, the only way that these images would currently not be validated is if the keys match.
You need to log in before you can comment on or make changes to this bug.