[Bug 25587] Be more clear that progress events are about bytes being transferred

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

Takeshi Yoshino <tyoshino@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tyoshino@google.com

--- Comment #3 from Takeshi Yoshino <tyoshino@google.com> ---
(In reply to Anne from comment #2)
> https://github.com/whatwg/xhr/commit/b9f6bcf9800963eb450b20cc96492a670fb96a99

This change includes addition of "with 0 and 0" to fire a progress event
algorithm steps in "request error steps" (current name). With this, people will
see:
- progress ProgressEvent with x and y
- progress ProgressEvent with x' and y
...
- readystatechange event with DONE
- progress ProgressEvent with 0 and 0
- error/abort/timeout ProgressEvent with 0 and 0
- ...

Looking at only the ProgressEvents, it looks good that we're no longer
dispatching a misleading progress ProgressEvent with normal non-zero loaded
value after setting response to a network error.

But, for example in Blink, we've been using the last loaded/total value for the
events since it was not well specified in the spec. Using the last "loaded"
value for the error/abort/timeout event allows the user to know around which
point the error occurred. Maybe useful for debugging.

So, my gut feeling is we should remove "fire a progress ProgressEvent" step
from the algorithm but make "fire a _event_ progress ProgressEvent" and maybe
"fire a loadend ProgressEvent" to use the last loaded/total value.

WDYT?

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

Received on Tuesday, 12 August 2014 09:12:11 UTC