Description

Making when to throw exceptions more intuitive.

Motivation

Additional details

With my experiment with Google Chrome 131.0.6778.70, following things didn't throw exceptions:

• Making start greater than end: editContext.updateSelection(10, 5);
• Making start and end zero: editContext.updateSelection(0, 0);
• Making start and end negative: editContext.updateSelection(-1, -2);
  • This resulted in having both of start and end at the end of text.

What to do with negative start and end doesn't seem defined and I thought that there may be an environment where exceptions are thrown in such cases.

However, the other cases seems quite natural and I don't think exceptions should be thrown in such cases.

• Zero is used to represent the head of the string. It is quite natural to select from there or to move the caret there.
• Having the end of the selection before the start of the selection is explicitly allowed. Therefore, there doesn't seem reasons that prevent this method from setting such selections.

Quote from the definitions of EditContext state in EditContext API:

• selection start which refers to the offset in text where the selection starts. The initial value is 0.
• selection end which refers to the offset in text where the selection ends. The initial value is 0. selection end may be less than selection start in the case of a "backwards" selection (in reverse of document order).

The "selection start" and "selection end" are what are set based on start and end passed to updateSelection() in the EditContext Interface.

Related issues and pull requests