I think we should tests this in a couple other places as well, to ensure implementations end up supporting this correctly (or already support it correctly?):

• FileAPI/blob/Blob-constructor.any.js
• encoding/encodeInto.any.js
• fetch/api/response/response-clone.any.js
• html/infrastructure/safe-passing-of-structured-data/shared-array-buffers/window-simple-success.https.html
• xhr/send-data-sharedarraybuffer.any.js

Thanks, I'm not a big fan of making support conditional. Is that needed for some implementations?

I think the first place I encountered missing support was crypto.getRandomValues. However it’s unclear to me whether it should or shouldn’t work even after these changes now that I’m looking at the spec. Perhaps one of you will find this clearer than I do.

The argument type for getRandomValues is ArrayBufferView, but the operation steps begin with this step:

1. If array is not of an integer type (i.e., Int8Array, Uint8Array, Int16Array, Uint16Array, Int32Array, Uint32Array or Uint8ClampedArray), throw a TypeMismatchError and terminate the algorithm.

I haven’t found anything defining what it means for an ArrayBufferView to be “of an integer type.” Web IDL does define “integer type,” but TypedArrays are ES objects whose indexed members model ES Number or BigInt language values. They have associated constraining “element types” (e.g. Int8), but despite the general alignment (e.g. Int8 → Byte), these aren’t really Web IDL integer values, so it doesn’t seem like the Web IDL term would be applicable here?

Stepping back from muddling through a search for a formal answer about how to read this, though: does anybody know what the intention might have been? At the time this was written, I’d guess they specifically wished to forbid Float32Array and Float64Array ... and ... maybe forgot DataView exists? I dunno.

If “of an integer type” really isn’t defined, I’d like to say big ones count (the most integer type of all, perhaps!) — but w/o knowing the rationale for the original constraint, I don’t feel confident making a case for that.

@bathos that specification seems woefully imprecise. I recommend filing an issue. It does seem like something that ought to work.

Hi @web-platform-tests/wpt-core-team. I'd like to merge this PR, which changes idlharness and thus potentially affects a lot of tests. However, the stability bots are unhappy about some pre-existing flakes:

• Firefox: /html/infrastructure/safe-passing-of-structured-data/shared-array-buffers/blob-data.https.html
• Chrome: /webtransport/idlharness.any.html

Is there a way to merge the PR anyway, despite the required statuses failing?

@TimothyGu yes if you've looked into the flakiness and it's pre-existing / unrelated then we can admin merge and bypass requires CI checks. I'll do just that.