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:
  • Change loaded and total attributes in ProgressEvent to double web-platform-tests/wpt#50714
• Implementation bugs are filed:
  • Chromium: https://issues.chromium.org/issues/381969448
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1943649
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=288688
• MDN issue is filed: Update ProgressEvent documentation to show it allows doubles mdn/mdn#641
• 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.

[smaug----]

Bug with a patch https://bugzilla.mozilla.org/show_bug.cgi?id=1943649 (webidl codegen for events is nice in this case)
Waiting for the tests before landing ;)

[domenic]

Should we merge this now, since all the boxes are checked? Or would we prefer to wait to see this land in Chromium to prove web-compatibility?

(I think that this one is so low-risk that there's no need to wait, personally. Unlike whatwg/webidl#1465 where waiting would be more prudent.)

[annevk]

I think it's okay to merge this around the same time the tests are merged.

[smaug----]

FWIW, I landed the patch to Nightly, waiting for the tests now ;)

[domenic]

We got approval to ship in Chromium now, so the tests should land very soon!

[domenic]

The tests have now merged, so I went ahead and merged this spec PR. Thanks all!

[annevk]

@smaug---- I think your IDL-only change might be insufficient, unless bindings work rather differently in Gecko. At least I had to change some C++ to get tests to pass, which also made me realize that there's a couple more throwing cases now, but hopefully none that people run into in practice.

[smaug----]

As I explained on Matrix, in Gecko one can create the full C++ implementation out of a "normal" kind of Event interface..