selectionStart should not be nullable: TSJS-lib-generator regression in 2.8.x

[styfle]

TypeScript Version: 2.8.1

Search Terms:
selectionStart, selectionEnd

Code

// Source code from https://github.com/styfle/copee
function fromElement(el: HTMLInputElement | HTMLTextAreaElement, preserveSelection?: boolean) {
    let start = 0;
    let end = 0;
    let success = false;

    if (preserveSelection) {
        start = el.selectionStart;
        end = el.selectionEnd;
    }

    el.select();

    try {
        success = document.execCommand('copy');
    } catch (err) {
        success = false;
    }

    if (preserveSelection) {
        el.setSelectionRange(start, end);
    }

    return success;
}

Expected behavior:
el.selectionStart and el.selectionEnd should return number

Actual behavior:
el.selectionStart and el.selectionEnd actually return number | null

Playground Link:
Playground

Related Issues:
#22381 , styfle/copee#21

[mhegazy]

looking at the spec, seems like null is a possible value for selectionStart and selectionEnd.

[styfle]

@mhegazy Interesting. It looks like type=text is never null but type=email is null for example.

1. Is there a way to tell typescript that the HTMLInputElement is type=text?
2. Also, why did this change in TS 2.8? Was it just wrong the whole time?

[mhegazy]

Is there a way to tell typescript that the HTMLInputElement is type=text?

Do not think there is a simple way to do this really.

Also, why did this change in TS 2.8?

We auto-generate the library from the webidl file from edge. see https://github.com/Microsoft/TSJS-lib-generator. We have taken an update to the file in 2.8.

Was it just wrong the whole time?

the input file can have bugs, and it can be wrong.. so yes.

[mhegazy]

if you are sure it is not null, you can use the null assertion operator !

[styfle]

Oh yeah, the null assertion operator is new.

But now that I think about it, the user may pass in an input element that I don't the type.

So I'll just fallback to 0, just in case.

Thanks 👍