Seek target range

[jesup]

the webidl has
[[EnforceRange](https://webidl.spec.whatwg.org/#EnforceRange)] required [unsigned long long](https://webidl.spec.whatwg.org/#idl-unsigned-long-long) at;

However the WPT test of negative seek targets for SyncAccessHandles looks for dom NotSupportedError; the webidl spec says it should throw a TypeError. Likely this is simply a bug in the WPT test

[a-sully]

Yup, that's an error. Looks like the Chrome implementation was missing the [EnforceRange] in our idl file, which caused this to slip through the cracks. I have patch up to fix this and update the WPT

[a-sully]

After thinking about this a bit more, we might want to consider what the other end of the target range looks like, as well. Using an unsigned long long makes sense to guarantee the value is non-negative, but most operating systems do not support offsets of more than the max long long (off_t is signed, for example). And 32-bit OSes may not even support more than the max long.

Should we have language in the spec about what to do if the value is not valid for file operations on that OS? (InvalidModificationError? TypeError?)

[a-sully]

The WPT has been updated to throw a TypeError if a negative value is passed, but I'll leave this issue open for the discussion of what we should do when an offset is passed which is too large for the underlying OS to handle

[annevk]

Using a TypeError as well seems reasonable.

[a-sully]

Thoughts on NotSupportedError, since whether the value is supported as an offset may depend on the OS? (sorry, I'm not sure whether this is consistent with how the error code is used elsewhere.) Otherwise TypeError seems reasonable to me :)

[annevk]

That could work as well, to some extent this depends on whether we expect web developers to branch on the exception type. If we don't, using the generic exception is preferred (that's TypeError to be clear).

I don't think we'd expect web developers to branch here. At least not based on this, but I could be mistaken. It seems to me that if the OS limit needs to be exposed there are better ways to do that, e.g., through a static getter.

[a-sully]

Good point! I'll update Chrome's implementation to make this a TypeError. We probably can't write a WPT asserting this (since some OSes/browsers could support values above the max signed long long) but we should add a note in the spec (#21).