Bug 4490 – Modifying an img WebResource only updates display the first time

• Status: RESOLVED
• Resolution: INVALID
• Component: DOM

[George Orthwein]

Summary
Using addSubresource to modify/update the image data for a WebResource of a particular URL 
(sometimes) works the first time, but subsequent changes to the image data do not display.

Steps to Reproduce
1) create a webview
2) create a WebResource with jpeg data, a unique URL, mime type "image/jpeg" and nil for text 
encoding name and frame name. The URL should have a made up protocol "asdf://" 
3) use addSubresource to add the WebResource to the WebDataSource of the webview.
4) Insert an image using the unique URL into the DOM
5) The image appears
6) Repeat steps 2-5 (creating different jpeg data for same URL) and the new image will not change it's 
display to reflect the new image data

Expected Results
The display of the image should update every time the appropriate WebResource is modified/
overwritten by addSubresource. I'm not sure if you should then have to insert/replace the image into 
the DOM or if all images using the URL of the WebResource should immediately update.

Actual Results
The display is updated on the first modification, but subsequent updates do not display.

Regression
Display results depend on the unique URL you assign to the WebResource.
a) An unregistered custom protocol (i.e. made up string such as asdf://) appear to use the data 
assigned in the WebResource... only once and then the display isn't updated after that.
b) If you assign a url with a scheme of file:// (or relative link, i.e. <img src="image.jpg">, then the 
modified data in the WebResource is never displayed. Instead it appears that new data from the URL is 
being fetched and displayed. If the file:// path is valid, you will see that data. If the file:// path is 
invalid, you will see a broken image.
c) If you assign a url with a scheme of http://, then it depends if the URL is valid. If it is valid, data from 
the URL is fetched and displayed. If it is invalid, then the modified data in the WebResource IS 
displayed... the first time.

This could be explained by the note on this page: http://developer.apple.com/documentation/Cocoa/
Conceptual/URLLoadingSystem/Concepts/CachePolicies.html
"Note:  Currently, only responses to http and https requests are cached. The ftp and file protocols 
attempt to access the originating source as allowed by the cache policy. Custom NSURLProtocol classes 
can provide caching if they choose."	

Is this a cache issue?

Notes:
A workaround is to create a new WebResource with a different unique url every time you want to modify 
the image.

Also filed in Apple Bug Reporter, Problem ID: 4212694

Here is sample code demonstrating the issue. Look in the three methods at the bottom of Document.m.
http://home.comcast.net/~george.orthwein/MiniBrowser_addSubresource_Example.zip

[George Orthwein]

Created attachment 3435 [details]
Modified MiniBrowser example showing bug in action

[George Orthwein]

This bug appears to still exist after updating to 10.4.3.

[Michael J. Cohen]

confirmed on 10.4.3 and r11976.

[Joost de Valk (AlthA)]

Reassigning to webkit-unassigned, to make sure more people see this.

[Joost de Valk (AlthA)]

Confirmed.

[George Orthwein]

In case it helps anyone looking at this bug, Apple DTS seemed to think it was an expiration issue with the "webKit cache" as opposed to the foundation data loading cache. 

Additionally, this same problem occurs when using a custom NSURL protocol (without addSubResource). If, say, the protocol renders an image with a random color, the image will not refresh when reinserted into the DOM. I think this may point to a larger image cache issue that only occurs when using these non-standard image generation methods (images created only in memory).

[Eric Seidel (no email)]

I'm pretty sure if a bug exists here, it should be tracked in Radar, not bugs.webkit.org