User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20100101 Firefox/10.0 Build ID: 20120129021758 Steps to reproduce: As part of my add-on, I need to extract binary data synchronously from any images loaded on the webpage from the local cache (if they don't exist in the cache then the function can return null) function getCachedImage(url) { var result = null; var xhr = Components.classes["@mozilla.org/xmlextras/xmlhttprequest;1"].createInstance(Components.interfaces.nsIXMLHttpRequest); xhr.open("GET", url, false); xhr.responseType = "arraybuffer"; // <-- error xhr.channel.loadFlags |= Components.interfaces.nsIRequest.LOAD_FROM_CACHE|Components.interfaces.nsIRequest.VALIDATE_NEVER; xhr.send(null); if(xhr.status == 200) { var arrayBuffer = xhr.response; if (arrayBuffer) { // do something with arrayBuffer // assign result to result } } return result; }; Actual results: On the highlighted line, the following exception is thrown; [Exception... "A parameter or an operation is not supported by the underlying object" code: "15" nsresult: "0x8053000f (NS_ERROR_DOM_INVALID_ACCESS_ERR)" location: "chrome://my-addon/content/my-file.js Line: 501"] Expected results: The exception should not of been thrown.

From nsXMLHttpRequest::SetResponseType: >1041 // sync request is not allowed setting responseType in window context >1042 if (mOwner && >1043 !(mState & (XML_HTTP_REQUEST_UNSENT | XML_HTTP_REQUEST_ASYNC))) { >1044 LogMessage("ResponseTypeSyncXHRWarning", mOwner); >1045 return NS_ERROR_DOM_INVALID_ACCESS_ERR; >1046 } This is a sync XHR, so this is expected.

http://www.w3.org/TR/XMLHttpRequest/#the-responsetype-attribute confirms this behaviour.

Thanks for the link. Whilst I agree async is the way to go for comms requests, in this particular case images are already in memory and being displayed (the add-on does the get(s) for the images after the page is displayed). So I'm struggling why I need to change to an async request (which involves a massive code change on my part) for something thats already in memory! Assuming the resolution stays at "WONTFIX", is there any other alternative to synchronously read the binary data (either via the cache, or direct via the DOM attributes)? Thanks Mark

So you want to get at the image data, but you want the compressed image data, not the uncompressed pixel data?

Ideally the compressed image data (for backwards compatibility), but could use the uncompressed pixel data. If your wondering why; I generate a 256 bit hash for each image on a webpage, so that I can detect whether any of the images are being re-used on other webpages (even if the uri changes).

> in this particular case images are already in memory and being displayed The latter does not imply that the compressed data (which is what XHR gets) is in memory. In fact, it may well not be available at all anymore to the network layer, which is what you're asking it for. So I believe the XHR aspect of this bug is in fact wontfix unless the spec changes. That said, you can of course always just ask for the responseText instead; it would be less efficient, but would sort of work. That said, it sounds like you really want a way to ask imagelib for the data for a given image...