On 07/06/2022 20:16, Jacek Caban wrote:
On 6/6/22 20:21, Gabriel Ivăncescu wrote:
On 06/06/2022 20:40, Jacek Caban wrote:
On 6/6/22 14:24, Gabriel Ivăncescu wrote:
For some reason, Gecko returns an XML document here, but native follows the spec.
That doesn't really make sense, Gecko is not involved because we currently use msxml instead of Gecko here. I guess you're referring to your future patches, in which case the question is what's "some reason"? Looking at Gecko sources, it returns XML document only for XML_HTTP_RESPONSE_TYPE_DEFAULT and XML_HTTP_RESPONSE_TYPE_DOCUMENT response type. What's wrong with that?
Similar question applies to overrideMimeType, why can't we let Gecko handle that?
Jacek
I meant if we use Gecko's responseXML to check whether it's NULL or not. For "default" case (no override), Gecko returns a non-NULL xml doc, even if Content-Type is not valid the way IE treats it. So we can't use it to check this (I tried it first since it's simpler).
It does do the right thing with overrideMimeType, but if we use it, we'll override *any* content type, which is not good either. Well at least not good enough to match native IE.
The whole thing seems to me like working around a problem somewhere else. My guess would be nsio.c, which has hacks for things like GetContentType(), but it's hard to tell without looking deeper. Did you rule that out somehow?
Jacek
I haven't looked into that, I wasn't aware it affects XMLHttpRequests. Skimming through it, it doesn't look like it would affect it (text/html is invalid in IE, not sure if Gecko treats it as valid XML to parse), but I'll investigate it more tomorrow.