- From: <bugzilla@jessica.w3.org>
- Date: Wed, 15 Dec 2010 09:15:14 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11548 --- Comment #4 from Simon <slgard@gmail.com> 2010-12-15 09:15:14 UTC --- What I meant by "in it's domain" is that javascript probably shouldn't be able to modify the cached entries of non-same-origin documents. Sorry to be vague about it, but I'm guessing you guys spend more time thinking about cross-domain scripting vulnerabilities than I do :) Although now that I do think about it, this could surely be done quite safely if the cache of the non-origin items were only viewable from the requesting domain (if that makes sense? > That's probably a feature not a bug. I've no doubt it's deliberate, but it seems logical to me that the client should be able to change it's mind and cache what it likes. >Anyhow, if you really want to preserve image state without reference to the >original resource, load it into a canvas bitmap and persist that. I've thought about suggestions like that (such as converting the image data to a base64 string) but I have 1000's of images that I'd like to cache. doing the conversion for 1000's of images is likely to be slow and I'd probably end up wanting a way to cache the base64 -> binary conversion :) My question ultimately becomes, why can't javascript dynamically update the manifest data? Or making localStorage able to store binary data might be a more flexible solution? It would also be nice to allow apps to request more than the 2-5Mb of localStorage that currently seems to be provided? -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 15 December 2010 09:15:17 UTC