[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 #8 from Takeshi Yoshino <tyoshino@google.com> ---
(In reply to Anne from comment #7)
> We fire a last event named progress to ensure you can finish animations and
> such that hang off it. I guess we could opt not to fire one in case of an
> error scenario though. Seems a bit ugly.

Yes. I'm not talking about successful case. Only an error scenario.

But when I was investigating Bug 26736, I saw this Glenn's post
http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0993.html . I
understand the following argument.

> For download progress you can work around this by watching onload and
> treating that as a progress(total, total) event, but that shouldn't be
> required.

Similar logic could be applied to error scenarios. I.e. we could say that we
should be able to know some error occurred by looking at only "progress"
ProgressEvents. And then, we'll e.g. change the color of the progress bar to
red when it sees "loaded" becoming 0 from non-zero or "total" becoming 0 from
non-zero.

Do you think this is useful?

Hmm, it also seems a little ugly if we make transmitted and length to the last
value before error (for debugging).

> 
> Are you suggesting we store the /transmitted/ and /length/ variables on the
> XMLHttpRequest object so they can be reused by the final error events?

Right. That's what we're doing now in Blink.

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

Received on Friday, 5 September 2014 13:51:14 UTC