Allow doubles for ProgressEvent's loaded and total

[domenic]

This allows specifications to use ProgressEvents while not necessarily giving away the exact number of bytes, for example by using numbers between 0 and 1. See discussion in webmachinelearning/writing-assistance-apis#15 for the concrete use case.

• At least two implementers are interested (and none opposed):
  • Chromium is interested
  • Per comments in this thread, WebKit and Gecko are supportive
• Tests are written and can be reviewed and commented upon at:
  • I will get these written. The test is basically how synthetic ProgressEvent behavior changes: fractions are preserved, and negatives are now passed through as-is instead of subtracted from 2^64.
• Implementation bugs are filed:
  • Chromium: https://issues.chromium.org/issues/381969448
  • Gecko: …
  • WebKit: …
• MDN issue is filed: … definitely need one for this change.
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

I wanted to get this PR up to judge implementer interest. It would be a decent bit cleaner if we all agreed this was reasonable and merged the change now, instead of having to float a patch in the relevant specs and thus causing all the databases to have two definitions of ProgressEvent.

---

Preview | Diff

[annevk]

I'll double check, in principle it seems fine. @smaug----?

[smaug----]

Should be fine.
Technically not backwards compatible, but I'd be a bit surprised if someone relied on the number -> long long conversion when calling the constructor.

[annevk]

If you could ping me once Chromium has successfully shipped this I'd appreciate this and I'll be sure to align WebKit at that point.

[domenic]

Awesome. I'm hoping to delegate the implementation and tests to someone else so it might be a week or so, but once we have tests up I'll update this thread with a link to them and open other-browser bugs. And I'll ping again once we have it shipped.