717221 - XMLHttpRequest progress events provide incorrect information for compressed responses

Status: RESOLVED DUPLICATE of bug 614352

(Core :: DOM: Core & HTML, defect)

Description

[Tom]

Attachment: evt.loaded/evt.total

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Build ID: 20111223083612

Steps to reproduce:

Added progress listener as described in https://developer.mozilla.org/En/XMLHttpRequest/Using_XMLHttpRequest#Monitoring_progress

Made request for a gzip compressed XML file.


Actual results:

Progress reported goes over 100%.

Response:

HTTP/1.1 200 OK
X-Powered-By: PHP/5.3.8
Content-Type: text/xml; charset=utf-8
Expires: 0
Content-Encoding: gzip
Content-Length: 385569
Date: Wed, 11 Jan 2012 13:54:11 GMT
Server: lighttpd/1.4.26


Expected results:

evt.loaded should contain the length of the compressed data not the decompressed data.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

evt.loaded should contain the length of decompressed data. It is the total which is wrong.

this is a dup of some other bug.

Comment 2

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

From the spec: "Initialize the loaded attribute to the number of HTTP entity body octets transferred."

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

ah, right.
Well, that is not very useful value for a webpage. It is just some "random" number which may or 
may not correlate what the XHR actually has processed (and how much data is actually available in
XHR).

But anyway, this is a dup.

Comment 5

[Tom]

I'm not sure this is a duplicate. I filed this bug because updating from Firefox 8 to Firefox 9 broke previously working code. The cause of this bug is some change between 8 and 9 not something that broke way back in 3.6.

Comment 6

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

That's interesting.  Can you provide a test case or a website that shows the bug?

Comment 7

[Tom]

Try http://nsbetdemo.neosoft.ba/test.html