Specify that the requests error should go back to the unset state

[stelar7]

While running asynchronously execute a request, request's error is set to undefined.
In most cases this would mean the JS value undefined, but in this case, its supposed to go back to the unset state.

Im not sure if there is a better spec wording for this 😅

The following tasks have been completed:

• Confirmed there are no ReSpec/BikeShed errors or warnings.
• Modified Web platform tests (link to pull request)

Implementation commitment:

• WebKit (https://bugs.webkit.org/show_bug.cgi?id=)
• Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=)
• Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=)

---

Preview | Diff

[SteveBeckerMSFT]

Hi @stelar7, thanks for the change. Could you please elaborate more on why this change is required?

The language Set "X" to undefined. is used throughout the spec. Are undefined and unset equivalent?

[stelar7]

Having the spec say set implies that it has a value, but in this case it should go back to the 'no value has been set' state.

It might just feel that way to me because this is the only field that has the concept of unset in combination with an optional value

I'm fine with closing this if you think the current text clearer in wrt. how the specs are written

[SteveBeckerMSFT]

I think the current text is probably OK. Setting to undefined should be equivalent to the no value has been set state.