On Tue Feb 21 15:08:16 2023 +0000, Jacek Caban wrote:
It's not clear to me that we need to worry about `responseText`'s length in such cases or at least I don't think that spec gives such guarantees (https://xhr.spec.whatwg.org/#the-send()-method, 'If not roughly 50ms have passed since these steps were last invoked, then return.' for example). Sync XHRs aside, the assumption that `responseText`'s length matches progress event is only valid inside the handler, not between events. An impact of sync XHR inside event handler is less clear, but it still seems fine to me to continue aggregating async XHR data in that case.
The problem isn't matching it necessarily exactly, but rather that it must be *at least* as long as the last one reported, never *less*.
In the example I gave, progress event gets called, some progress is reported in `responseText`, e.g. "123456". Subsequent calls must always return *at least* "123456", never less (not "12345" or anything less).
Now imagine that the script stores the value of responseText into a global variable. Nothing out of the ordinary here. Now it's "123456". It expects that it's always increasing, and never less, so it can't become shorter like "12345". This is perfectly fine.
Next, we're out of the blocking call, maybe out of the handler entirely. It's not blocked now, and `responseText` gets called again. We didn't receive or dispatch any progress events yet, but this time, Gecko reports "1234567" (which is perfectly valid). The script now stores "1234567" in the global variable, or something to that effect.
So far so good. But what happens if we now block inside a sync_xhr send() and something calls async_xhr.responseText?
What will we return? We can't return Gecko's value, because we're blocked, and it could be even further, perhaps completed even. We can't return the former "state saved at progress event" either, because that was "123456", which is shorter than "1234567" and breaks the assumptions that it can never be less!
So we have to keep track of it even when we call responseText when non-blocking. In this case, update it to "1234567", so now we return "1234567", which doesn't break the "it can't be shorter" constraint.
Anyway this isn't a big deal? It's just the update in get_responseText. SysAllocString() would calculate the length anyway, so it's not a performance issue either for long responses.
I don't think it should be an issue?