Jacek Caban (@jacek) commented about dlls/mshtml/xmlhttprequest.c:
nsAString_Init(&nsstr, NULL); nsres = nsIXMLHttpRequest_GetResponseText(This->nsxhr, &nsstr);
- return return_nsstr(nsres, &nsstr, p);
- if(NS_FAILED(nsres))
hres = map_nsresult(nsres);- else {
nsAString_GetData(&nsstr, &text);if(!text || !text[0])*p = NULL;else if(!(*p = SysAllocStringLen(text, This->responseText_length)))hres = E_OUTOFMEMORY;nsAString_Finish(&nsstr);
I'm not sure we want to handle it like that. I guess that you want progress event values to match returned responseText length, but it's not clear to me why would we report all progress events when unblocking. For example, if we blocked three progress events with loaded value of 10, 20, 30, shouldn't we just report a single event with loaded value 30 when unblocking? If we supported it, then this patch would then be redundant.
That rises a question if we want to queue XHR events at all. The alternative would be, when blocked, simply record a pending state in XHR object and queue a single task. That task would then use pending state to synthesize required events when unblocked, somewhat similar to what you do in the last patch for IE9 mode. I think such approach would both improve the above example, but also get rid of other corner cases like: async XHR starts, gets blocked by sync XHR, async finishes loading, scripts sets loadend listener. When XHR sync completes, it unblocks queued events, but loadend does not fire because it wasn't bound then Gecko event happened. What do you think?