Add note that signal is always initialized
#1856
Conversation
The getter steps [1] specify to return `this.signal`. Its signal is nullable [2] and therefore the getter should also be nullable. [1]: https://fetch.spec.whatwg.org/#dom-request-signal [2]: https://fetch.spec.whatwg.org/#request-signal
|
This seems editorial to me, but I am actually not sure. Do let me know if this does require test coverage and all if it turns out it is normative. |
|
I don't think this is correct. While it does start out as null, it is always initialized. By the time the getter returns it will always get an |
|
Hm, I am implementing it in Servo atm and it does return null sometimes. I haven't been able to figure out why though. Should we maybe update the steps to assert it is not null and then return this.signal? That makes the invariant explicit |
|
I think IDL is that assert. And in a future world the Web IDL specification should have such a generic assert in its getter wrapper. (That what the specification returns matches what it needs to return, or at least matches that post any Infra-to-IDL-to-JS-type conversion.) |
|
Will investigate why Servo is running into the assert and let you know if it is an implementation issue or not. |
|
Seems like I missed implementing the parts of |
|
A note for the getter? I suppose that's reasonable. |
TimvdLippe
changed the title
AbortSignal as nullablesignal is always initialized
2 participants
The getter steps 1 specify to return
this.signal. Its signal is nullable 2, but it is always initialized in the constructor and when cloning.Preview | Diff