When editing, the user may want to make changes to images used for <img> or "background" attribute on other tags. Currently, changes in an image are not refreshed, even if you clear both memory and disk caches via preferences. We don't generally talk to ImageLib directly, however; image loading is done by layout through normal DOM + layout. Pavlov explained that forcing the image load is certainly possible, so a suggested way to make this happen in editor is to add a "-moz-force-imageload" attribute where appropriate to tell layout to reload image from source file. Because of the problem of using image backgrounds on *any* tag (e.g., via "background" attribute or CSS), however, I wonder if we still might want an API so editor can force reload of specific image URLs, or maybe all image in a page?

[imagelib]

This is very important to Composer! Can we please get a milestone on this?

marking nsbeta1 then to try call some attention to this

there is no way i'm going to get to this anytime soon.

This issue is now being examined in bug 82435

Couldn't this bug be solved by adding an API to the cache that lets the editor evict a specific URL from the cache, then neither the content model code, image frame code nor imagelib would need to know anything about this editor specific requirement?

Charles, this can be fixed w/o changes to imglib or any other non-editor code, here's how... Before changing img.src in the editor JS code, the editor code can get the loadgroup from the document/window where the image is and set the attributes on the load group so that the image is loaded from the network and not from the cache, then once the img.src is set the editor can swap the loat attributes back. To do this you just get the URI loader service, call getLoadGroupForContext(image_window) on the uri loader and set the LOAD_BYPASS_CACHE flag on the loadgroup, once you've changed the src then you set the loadgroup flags back to whatever they were before you started... Reassigning to cmanske.

This suggested strategy probably doesn't work. "image_window" in getLoadGroupForContext(image_window) is an nsISupports *, but it is really a nsIDocShell, and we do not (and should not) have access to that in JavaScript. Thus getLoadGroupForContext is really unusable from JS. CC'ing mscott, who's the expert for uriloader code.

AFAIK there is not, nor should there be, anything stopping you from accessing a docshell from *chrome* JS.

Ohhh kaaay, then how do I? MScott?

Currently there are no hooks to get the docShell for a nsIDOMWindow. Unless you are suggesting we add to nsIDOMWindow =). The only API that exposes the docshell to a window type object in JS is if you have a browser tag in your XUL. Access to the docshell is built into the browser XBL widget.

Bug 82435 now has a good fix: There's a new method "imgICache::removeEntry" that allows us to remove a URL from the image cache, forcing a fresh reload. This method is used in the fix to bug 78351, so once all the fixes to bugs 76177, 82435, and 78351 are checked in, this will automatically be fixed.

moving off to 0.9.3 since this bug will be resolved with fixes from other bugs

With the 6/15 changes made to fix bug 78351, the user can force reloading any image by simply launching the Image Properties dialog (double click on an image in the document). Thus we are no longer dependent on bug 76177. Since all other dependencies are fixed, I think we can consider this fixed!

Verified in 8-27 Build

[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.