On Wed Feb 15 16:27:50 2023 +0000, Jacek Caban wrote:
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?
Interesting, that sounds reasonable. I'm not *entirely* certain how Progress is supposed to work here. In your example, it could even set the loadend handler in one of the readystatechange handlers, and yeah that needs fixing for sure.
What I mean with progress events is that, for example, not sure if they're sent after specific time, or after % completion or some other criteria. It's not guaranteed, right? Wouldn't want some script relying on something unreliable like that (e.g. if downloading 1 MB, expect 3 progress events or something). So if "batch" them up and merge them to then send only one at the end, it would "break" this assumption but:
* I doubt it's even how it works or reliable enough. * I doubt scripts would use it, usually they use progress to update some visual indication so it doesn't seem stuck. * I doubt Gecko even precisely matches Windows, since nothing is said in the spec when they're sent. Quick test reveals they are dispatched at different times anyway.
BTW from quick testing it also seems we have to dispatch progress event, even if it goes straight to DONE. progress→readystatechange (DONE)→load.