1227674 - loaded property of XHR progress event reports pre-content-decoding sizes

Status: RESOLVED WONTFIX

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

Description

[benweint]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20151029151421

Steps to reproduce:

1. Go to this JSFiddle: http://jsfiddle.net/jpbvenoe/
2. Compare the 'loaded' property of the last progress event and the final length of the responseText


Actual results:

The 'loaded' property of the progress event reports the loaded size pre-content-decoding (that is, the compressed size in this case, since the resource being fetched is gzipped), whereas the responseText property of the XHR returns the post-content-decoding body.


Expected results:

The 'loaded' property should report post-content-decoding sizes. This is what happens in Chrome, Safari, Edge, and IE 10+, and seems to be what's called for in the XHR spec.

The loadend event suffers from the same issue.

Comment 1

[benweint]

It looks like this used to work correctly in Firefox 33, and broke in 34.

Comment 2

[Simona Badau, Desktop QA]

Perhaps there's someone with extensive knowledge on this area that might be able to help here.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> The 'loaded' property should report post-content-decoding sizes.

As far as I can tell, that's not the case per spec.  The spec says:

  Fire a progress event named progress with response's body's transmitted and response's
  body's length. 

where "transmitted" is defined in https://fetch.spec.whatwg.org/#http-network-fetch step 4 substep 2 and is clearly computed before undoing any content-encodings.

> This is what happens in Chrome, Safari, Edge, and IE 10+

Looks like they never updated to the spec clarification a year or so ago.  The other fun bit is "total".  Per spec they should be showing the Content-Length.  At least Chrome and Safari show 0 instead on <http://jsfiddle.net/jpbvenoe/2/>.  IE11 shows a garbage value for the first progress event, then the uncompressed final length for the second one; that's clearly broken behavior for the first event, at least.

> It looks like this used to work correctly in Firefox 33, and broke in 34.

Well, it was a purposeful change in 34, to align with the spec.  See bug 614352 where the links to the spec discussion are.

Anne, do you know what the story here in terms of whether other implementations ever planning to align with the spec here?

Comment 4

[Boris Zbarsky [:bzbarsky]]

And in particular, were there bugs raised against them when the spec was clarified?

Comment 5

[Boris Zbarsky [:bzbarsky]]

And note that the spec said what it currently says, though in somewhat different language, at least as early as January 2012.  See the spec quote in bug 717221 comment 2.

Comment 6

[benweint]

Ah, you're right re: the spec. Thanks for the reference, and sorry I mis-interpreted it in my initial reading!

In my specific use case, pre-content-decoding sizes are actually more useful, but more than that, I just want something that I can rely upon being semantically identical across browsers. If there aren't existing bugs against Chrome, Edge, and Safari I'd be happy to file some.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Looks like Blink has a bug report at https://code.google.com/p/chromium/issues/detail?id=463622 but it also sounds like they don't exactly plan to fix it so far.

Safari has https://bugs.webkit.org/show_bug.cgi?id=142232 (filed by the same reporter, actually), with no activity at all.

There's no obvious way to tell whether there's a bug on Edge, since their bug database is not public...

Comment 8

[Anne (:annevk)]

All I know is that per https://github.com/slightlyoff/ServiceWorker/issues/339 we went through the current design with the people from Chrome and had some kind of tentative agreement on how this should work. Since that change though the discussion in https://www.w3.org/Bugs/Public/show_bug.cgi?id=25587#c3 that started after never really concluded, but that does not seem related to this bug as far as I can quickly tell.

Comment 9

[Thomas Wisniewski]

Anne agreed with my proposal to just keep the pre-content-decoding sizes as per the current spec, so this bug might as well be closed as WONTFIX: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25587