nsiHttpRequest.responseType is not supported by the underlying object

RESOLVED WONTFIX

Status

()

Core
DOM
RESOLVED WONTFIX
7 years ago
7 years ago

People

(Reporter: mozilla, Unassigned)

Tracking

(Blocks: 1 bug)

11 Branch
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
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.
Component: Untriaged → DOM
Product: Firefox → Core
QA Contact: untriaged → general

Comment 1

7 years ago
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.

Comment 2

7 years ago
http://www.w3.org/TR/XMLHttpRequest/#the-responsetype-attribute confirms this behaviour.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 3

7 years ago
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
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
So you want to get at the image data, but you want the compressed image data, not the uncompressed pixel data?
(Reporter)

Comment 5

7 years ago
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...
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.