I'm sure this was already litigated so just point me to the resolution but ...

Lots of apps have a CSS based canvas size. That size can go to zero. Lots of apps set the size of their canvas (its backingstore) to the CSS size.

canvas.width = canvas.clientWidth  // or equiv using ResizeObserver or getBoundingClientRect

In Canvas 2D and WebGL this is valid, no problem. In WebGPU it's validation error. That means there are or will be lots of invalid webgpu apps waiting for the user to size something or add some content that effectively makes a canvas' size go to zero and then, not checking for size = 0 they'll start generating WebGPU errors.

-- edit --

I want suggest that getCurrentTexture should change to request a size like this

createTexture({
  size: {
    width: max(1, min(device.limits.maxTextureDimensions2D, canvas.width)),
    height: max(1, min(device.limits.maxTextureDimensions2D, canvas.height)),
  },
});

That would solve 2 existing problems.

1. That users making their canvas backingstore match their CSS display size need to check for sizes are not too large (and probably aren't checking)
2. That users making their canvas backingstore match their CSS display size really need to check for sizes are not zero (and probably aren't checking)

Note: I ran into this issue today in react app where in the first frame the canvas was 0 width, 0 height.

This doesn't seem like a breaking change, in fact the opposite, it's potentially a change that fixes existing broken programs and makes the API slightly more robust.

As it is, every app is effectively required to write the code above when setting the canvas size. You might think it doesn't matter and then later you change your app, or copy and paste the code, not realizing you have a time bomb in your app. With this change it seems like we can remove that time bomb or at least lessen its impact.