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

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

--- Comment #12 from Takeshi Yoshino <tyoshino@google.com> ---
(In reply to Glenn Maynard from comment #11)

Thanks. So, what do you think about my proposal at comment 6?

1) we remove "fire a progress ProgressEvent" step
2) have the "fire a _event_ ProgressEvent" step to use the last loaded/total
value than 0/0
3) have the "fire a loadend ProgressEvent" step to use the last loaded/total
value than 0/0

For (1), we could also do "fire a progress ProgressEvent with
lengthComputable/loaded/total as of the time error happened" than just removing
the step. I.e. we make sure we tell the final position to the user even if
there's throttling (like what you suggested for success case). I'm fine with
either as this is error case.

For the "error" and "loadend" event, I think providing
lengthComputable/loaded/total as of the time error happened would be useful for
debugging. But I don't have strong opinion about this.

When lengthComputable is false because chunked Transfer-Encoding is used,
currently IE, Chrome and Firefox are doing so for "loaded". IE sets total to
the same value as loaded and sets lengthComputable to true. Chrome and Firefox
leaves them 0 and false (as on comment 10).

> (By the way, you'd have a bug: the progress bar wouldn't become red if an
> error occurred before loading any bytes, since loaded was never nonzero.)

Right. It's not fully reliable. If lengthComputable is true and total is
non-zero, we can look at total going down. Otherwise, there's nothing from
which we can detect error only by "progress" ProgressEvent.

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

Received on Tuesday, 9 September 2014 06:18:25 UTC