CTS expects wrong result of mapAsync on invalid buffer

[sagudev]

On invalid buffer CTS expects:

cts/src/webgpu/api/validation/buffer/mapping.spec.ts

Line 155 in 81aeeb4

{ validationError: true, earlyRejection: false, rejectName: 'OperationError' },

and both firefox and chromium pass it, but spec says we should return abort and no validation error:

2. If any of the following conditions are unsatisfied:

   this must be valid.

   Set deviceLost to true.

   Issue the map failure steps on contentTimeline.
   Return.

If deviceLost:

Reject p with an AbortError.

This might also be spec issue as introduction PR of spec text talks about device loss, but here it's actually buffer invalidity part of code: gpuweb/gpuweb#5114 (this is buffer not device).

[sagudev]

cc @kainino0x

[kainino0x]

I think this is a spec typo, and it was meant to say this.[[device]] must be valid.

Right now, the spec says "if buffer is invalid, set deviceLost=true", which doesn't make any sense.

[sagudev]

But we should still be check buffer validity, no?

EDIT: Usually we do https://www.w3.org/TR/webgpu/#abstract-opdef-valid-to-use-with, but maybe we want separate errors for device invalid vs. buffer invalid

[sagudev]

there also does not seem to be any test for mapAsnyc on destroyed device

[kainino0x]

But we should still be check buffer validity, no?

Ah yes, true... probably accidentally missed that because the this must be valid of course makes it look like it is checked. It could also be the case that at some point I thought this.[[internal state]] is "available" requirement would check that. It doesn't, though.

there also does not seem to be any test for mapAsnyc on destroyed device

Offhand I'm not sure, but you're probably right.

[sagudev]

I prepared spec update gpuweb/gpuweb#10971 which raise AbortError (deviceLost=true) when device is invalid (lost) and raise OperationError on invalid buffer (in that order) as I think that was the original intention. Based on new CTS test this also matches the behavior of dawn.