Progress events should handle gzipped content

• Component: UI Events
• Status: REOPENED ---

[Jason Davies]

Demo: https://www.jasondavies.com/chrome-progress-bug/

The "total" field should be non-zero for each event, since the response has a content-length (relating to the compressed data), and the "loaded" field should indicate the amount of compressed data loaded so far.

See also:
- https://code.google.com/p/chromium/issues/detail?id=463622
- https://bugzilla.mozilla.org/show_bug.cgi?id=614352

[Jason Davies]

It might also be worth pointing out that much of the time, gzipped responses do not have a content-length header as it happens on-the-fly.  This bug only applies to the case where a content-length header is present.

[Ahmad Saleem]

Following was marked as "RESOLVED WONTFIX" by Chrome with following reasons:

Link - https://bugs.chromium.org/p/chromium/issues/detail?id=463622#c22

I'm closing this bug as WONTFIX from several reasons.

 - It is likely that some web developers rely on the current behavior. We don't
   love the current behavior, but fixing this kind of bug is hard.
 - WebKit's behavior matches with Chrome's, which makes me more reluctant.
 - We recommend web developers to use fetch() instead of XHR. If this feature
   should be fixed it should be introduced to fetch API.

So, if you want the progress events with the number of compressed bytes, I recommend to propose the correspondence for fetch API in https://github.com/whatwg/fetch/issues.

Thanks!

but Mozilla bug seems to fix it and had following W3C test:

https://wpt.fyi/results/xhr/progress-events-response-data-gzip.htm?label=master&label=experimental&aligned&view=subtest&q=progress-events-response-data-gzip.htm

STP 154 pass the test case, so I am marking this as "RESOLVED CONFIGURATION CHANGED". Please reopen if something else is needed. Thanks!

[Jason Davies]

This is still not fixed in either Chrome or WebKit, and the linked WPT test doesn't check to see if Content-Length is available; it shows "pass" if the implementation just sets lengthComputable=false.

The issue is that when a Content-Length is available *and* Content-Encoding: gzip is used, both Chrome/WebKit don't provide enough information for a progress indicator (based on bytes loaded over-the-wire/pre-decompression).  Both `loaded` and `total` are needed.

[Ahmad Saleem]

(In reply to Jason Davies from comment #3)
> This is still not fixed in either Chrome or WebKit, and the linked WPT test
> doesn't check to see if Content-Length is available; it shows "pass" if the
> implementation just sets lengthComputable=false.
> 
> The issue is that when a Content-Length is available *and* Content-Encoding:
> gzip is used, both Chrome/WebKit don't provide enough information for a
> progress indicator (based on bytes loaded over-the-wire/pre-decompression). 
> Both `loaded` and `total` are needed.

Thanks Jason for adding more context. Appreciate it!