Repository navigation
XMLHttpRequest Events in lib.dom don't match spec[?] #21414
Description
Overview
TypeScript's lib.dom.d.ts currently has incorrect type information for the XMLHttpRequest events. The current definition in the dom.generated.d.ts file:
interface XMLHttpRequestEventTargetEventMap {
"abort": Event;
"error": ErrorEvent;
"load": Event;
"loadend": ProgressEvent;
"loadstart": Event;
"progress": ProgressEvent;
"timeout": ProgressEvent;
}However, according to the [admittedly non-normative] spec, the above should all adhere to the ProgressEvent interface.
I ran into this "issue" because Chrome does not treat the parameter sent to the XMLHttpRequest.onerror callback as an ErrorEvent, but as a ProgressEvent.
I poked around a bit and found that the lib.dom.d.ts appears to be largely generated by the TSJS-lib-generator tool, which takes as input a Microsoft Edge spec file:
The input file is the XML spec file generated by the Microsoft Edge browser.
If this is indeed how lib.dom.d.ts is built, is there something that can be done to help adjust the declaration files to match a specific browser? Is it possible to generate spec files for other platforms?
Standard Info
TypeScript Version: 2.6.2
Search Terms: XMLHttpRequest ProgressError Event
Code
// The following produces an error because xhr.onerror expects an ErrorEvent.
const xhr = new XMLHttpRequest();
xhr.onerror = function (event: ProgressEvent) {
console.dir(event.target);
}Expected behavior:
The onerror callback does not complain when attempting to set a function that takes a ProgressEvent parameter.
Actual behavior:
The onerror callback complains when attempting to set a function that takes a ProgressEvent parameter.
Playground Link:
See it in action here!
Related Issues:
Maybe this one? ¯\_(ツ)_/¯
Activity
[-]XMLHttpRequest Events in lib.dom don't match spec[?[/-][+]XMLHttpRequest Events in lib.dom don't match spec[?][/+]mhegazy commentedon Jan 25, 2018
PRs welcomed. You can find more information about contributing lib.d.ts fixes at https://github.com/Microsoft/TypeScript/blob/master/CONTRIBUTING.md#contributing-libdts-fixes.
ericdrobinson commentedon Jan 26, 2018
Mohamed Hegazy (@mhegazy) Got it. Thanks.
Followup question(s):
<webidl-xml>element results in the following unhelpful error:The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.mhegazy commentedon Jan 29, 2018
we grab them from the Edge build output. it is internal at the moment, but we have plans to move to standard webidl in the future.
again, Edge internal docs, we do not have access to, nor do we (as the TS team) own.
alvincrespo commentedon Mar 16, 2018
I'm curious if this issue is related.
Basically
statusandresponseare not being picked up bytarget, which should be ofXMLHTTPRequest.Should I open up a new issue?
ericdrobinson commentedon Mar 16, 2018
Alvin Crespo (@alvincrespo) No, that's a different issue. The
ProgressEventtype is not specific toXMLHTTPRequest. TypeScript could potentially figure that out by analyzing the entire line and noticing thatxhr.onloadis a callback for anXMLHTTPRequestobject and therefore theevent.targetin the callback should be anXMLHTTPRequestinstance, but that seems like a pretty large bit of work (perhaps Mohamed Hegazy (@mhegazy) could say better whether that type of inference is feasible in TypeScript).The proper way to handle the situation you pointed out can be seen here. Another example that relies upon closures would look like this. (Personally I'm partial to the non-closure approach...)
Hope this helps!
alvincrespo commentedon Mar 16, 2018
Eric Robinson (@ericdrobinson) The two links you sent over still link to my example, perhaps a copy/paste typo?
Alos, the explanation you gave makes total sense - thanks for pointing that out. More than happy to help with this problem.
ericdrobinson commentedon Mar 16, 2018
Alvin Crespo (@alvincrespo) Sorry about that! I forgot to click the "Share" button to update the link before copying the link in the address bar (both times!). The links in the original comment are fixed!
alvincrespo commentedon Mar 17, 2018
Eric Robinson (@ericdrobinson) Oh cool! I totally didn't think about the casting approach! Thanks for the tip. Also, sorry for derailing the original conversation in this thread (to anyone who comes back to read this).