waiting on GM_xmlhttprequest to finish

[matej]

(sorry, this is probably slightly offtopic here and would be more
appropriate in greasemonkey-users Google Group, but I haven't got any
reply there when posted; I guess, it would work exactly the same with
plain xmlhttprequest, not only the GM_* one; actually, thinking about
it, I can use plain xmlhttprequest, because this is from the same
domain as the page)

Hi,

I have a script which works on http://bugzilla.redhat.com (it works
probably just for logged in users, who are employees of Red Hat --
normal users have slightly different webpages) and uses XMLRPC (via
http://webdev.yuan.cc/lib/xmlrpc.js and @require) to change MIME types
of some/all attachments to a bug. Whole script is also available on
http://mcepl.fedorapeople.org/scripts/fixAttachmentTypes.user.js

The problem I have is that after all GM_xmlhttpRequests I would like
to fire document.location.reload() Obviously GM_xmlhttpRequest is
asynchronous, so I tried this to cout how many outstanding requests
are unfinished and to fire the reload() only when it is zero:

/* global variable in the top of the script */
var reqCounter = 0;

/* ... skip ... */

/**
* Sends XMLRPC request
*
* @param url string with URL of the XML-RPC interface
* @param data string with XML of the data to be sent
* @param method string -- either 'post' or 'get'
* @param callback function catching callback
*/
function sendRequest(url,data,method,callback) {
GM_xmlhttpRequest({
method: method,
url: url,
headers: {
'User-agent': 'Mozilla/4.0 (compatible) Greasemonkey
fixAttType
XMLRPC',
'Accept': 'application/atom+xml,application/xml,text/xml',
'Content-type': 'text/xml',
},
data: data,
onload: callback,
});

}

/**
* Callback function for the XMLRPC request
*
* @param ret object with xmlhttprequest response
* with attributes:
* + status -- int return code
* + statusText
* + responseHeaders
* + responseText
*/
callBack = function(ret) {
if (ret.status != 200) {
alert([ret.status,ret.statusText,ret.responseHeaders,
ret.responseText]);
}
if (--reqCounter == 0) {
document.location.reload();
}

}

/**
* The worker function -- call XMLRPC to fix MIME type of the
* particular attachment
*
* @param id integer with the attachment id to be fixed
* @param type string with the new MIME type, e.g. "text/plain"
*
*/
fixAttachById = function(id,type) {
var msg = new XMLRPCMessage("bugzilla.updateAttachMimeType");
msg.addParameter({'attach_id':id, 'mime_type':type});
msg.addParameter(login);
msg.addParameter(password);
try {
var ret = sendRequest(XMLRPCurl,
msg.xml(),'post',callBack);
}
catch (e) {
window.alert(e);
}
reqCounter++;

}

I hoped that document.location.reload() now happens only when XMLRPC
requests are complete. Unfortunately, I still get webpage as if some
attachment types were not changed. Do I do something wrong, or do I
have to just add waiting for a second or two (presumably to wait on
bugzilla to catch up on the changes in the internal database)?

Any more thoughts?

Thanks for any reply,

Matej Cepl

 

[Bjoern Hoehrmann]

* matej wrote in comp.lang.javascript:

/* global variable in the top of the script */
var reqCounter = 0;

if (--reqCounter == 0) {
document.location.reload();
}

try {
var ret = sendRequest(XMLRPCurl,
msg.xml(),'post',callBack);
}
catch (e) {
window.alert(e);
}
reqCounter++;

It is not clear from these excerpts that you ensure the counter does not
reach zero because the requests finish faster than you can schedule them
(consider you send one request, it finishes, and then you never send the
second request). Also, if sendRequest fails you probably don't want to
increase the counter, though I don't know what sendRequest does.

I hoped that document.location.reload() now happens only when XMLRPC
requests are complete. Unfortunately, I still get webpage as if some
attachment types were not changed. Do I do something wrong, or do I
have to just add waiting for a second or two (presumably to wait on
bugzilla to catch up on the changes in the internal database)?

Generally such problems should be debugged by looking at the actual net-
work traffic using a network analyzer like WireShark or at least some
browser add-on that gives you access to what's going on there. That way
you can rule out many problems.