[Bug 23348] The loaded property doesn't make sense when the body is compressed

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23348

--- Comment #11 from Glenn Maynard <glenn@zewt.org> ---
I'm not seeing inconsistent .total and .loaded.  My test case is here:
https://zewt.org/~glenn/test-xhr-progress-events.html.  It downloads a
5000000-byte text file, compressed to 1370401 bytes with Content-Encoding:
gzip.  I set this up to ensure a Content-Length header is sent (Apache's
internal deflate support uses chunked, which defeats this test).

- Firefox 23 (needs retesting with 24) gives:

(loaded, total, lengthComputable)
0, 3153971, false
5000000, 5000000, false

It gives a bunch of progress messages with an e.total of 0, an e.length of the
fully decompressed size, and a false e.lengthComputable.  This doesn't match
the spec (as I understand it), but it matches the suggestion I made above.

(The final message has an e.total set to the final size, which seems fine. 
e.lengthComputable is still false, which is a bug, but that doesn't matter
here.)

- Chrome 29:

0, 5336, false test-xhr-progress-events.html:6
0, 2699630, false test-xhr-progress-events.html:6
0, 4865055, false test-xhr-progress-events.html:6
0, 5000000, false 

It does the same thing as Firefox, except without e.total set in the final
message.

- IE10:

 18446744073709552000, 4096, false 
 18446744073709552000, 8192, false 
 ...
 18446744073709552000, 4994966, false 
 18446744073709552000, 4999062, false 
 18446744073709552000, 5000000, false 

(Wow, that's broken: a garbage .total, and no onprogress rate limiting at all. 
Even better, its network console lies: the Content-Encoding header isn't shown
at all, even though sniffing the connection I can see that it's being sent.  I
guess IE is still IE.)  But, the .loaded value matches the others.

So, I'd recommend the spec use the number of post-Content-Encoding bytes for
.total and .progress, rather than the entity body (before C-E and T-E).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 25 September 2013 23:24:13 UTC