nvda

46e3697b - In the console history, when pressing up/down arrow and history start or end is reached, do not move the caret anymore (#12897)

In the console history, when pressing up/down arrow and history start or end is reached, do not move the caret anymore (#12897) Fixes #12632 Summary of the issue: In Python console, up/down arrow behaves as follow: If command history start or end is not reached, move to previous or next item in the command history. If command history start or end is reached, move the caret one character left or right; this is the default behaviour of some single line edit fields (cf. Up/down arrow should read character by character in single line edit fields #12780) The point 2. is an unintuitive corner case. Indeed, up/down arrow cannot be used generally in this field to navigate character by character, this is only partially possible in some rare cases, i.e. at the edge of command history buffer. Description of how this pull request fixes the issue: Navigation character by character with up/down arrows should be totally disabled in the console input field. The caret should not move at all if the line has not been updated. Testing strategy: Checked that up/down arrows still work in the console to re-read the command history When reaching the first command in history, pressed up arrow again and checked that the caret does not move left anymore (STR of Python console - The caret moves to left when pressing upArrow #12632). STR: Type various commands in the console Type a last command without pressing Enter Turn back some characters left with left arrow Press down arrow once and checked that the caret has not moved. Known issues with pull request: In the case the Narrator is used along with NVDA (which is a very unlikely use case): When pressing up arrow, the last character of the first command in history will be read instead of the whole line. An alternative solution that would be compatible with Narrator could be to use a multi-line edit field even if it is only filled with one line of text. But the implementation would be more complex; I do not think it is worth implementing it to support this very unlikely use case.