Add selection range checks to updateSelection, updateText and EditContext constructor.

[ltenmoz]

Fixes #88. I'm hoping it's not too late to change this. :)

For normative changes, the following tasks have been completed:

• Editing WG resolution on the proposed changes, with at least two implementers participating and not objecting:

  • WebKit
  • Chromium
  • Gecko

• For browsers that are shipping the feature, implementation bugs are filed for the proposed changes (link to bug, or write "Not Implementing"):

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

[ltenmoz]

Hmm actually, checking the bounds in updateText() breaks the Monaco code editor. It seems they are doing updateText(0, Infinity, newText) which I suppose is slightly more convenient than updateText(0, editContext.text.length, newText). So perhaps it's best to leave that out. With the other changes, Monaco, CodeMirror, and Google Docs all seem to work fine, which are all the EditContext users we discovered searching HTTPArchive. So I think it should be safe to make this change (let's hope…)

[ltenmoz]

Still, let's add steps here to make it clear that it's intended behaviour that these can be > text.length

[smaug----]

@dandclark

[dandclark]

We'll need to add some telemetry to Chromium to verify to what degree this will run into compatibility problems. If that data shows it can be done, I'd be in favor of this. If Monaco turns out to be the only ones who'd have problems with the change to updateText, we could potentially reach out to them to see if they'd be willing to make a change. It'd be nice to have updateText be consistent with the rest.

[ltenmoz]

Yes I agree it'd be better to have updateText throw as well, maybe it is worth reaching out to Monaco (although I suspect it might take a while for enough sites to update it that we could safely make the change…)