validate="always" on xul:image still caches it

NEW
Unassigned

Status

()

13 years ago
5 years ago

People

(Reporter: bugs.caleb, Unassigned)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
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.
(Reporter)

Updated

13 years ago
Blocks: 291369
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?

Updated

11 years ago
Assignee: pavlov → nobody
QA Contact: imagelib
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.