1463681 - Find a way to prevent to accidentally lose JsTerm content when navigating with arrow keys

Status: NEW

(DevTools :: Console, enhancement, P3)

Description

[Nicolas Chevobbe [:nchevobbe]]

**Steps to reproduce**
1. Open the console
2. Evaluate "hello"
3. Write (or paste) the following : 
```js
document.querySelector("*").
  length
```
4. Hit the Up-arrow key 3 times

**Actual results**

I accidentally navigated to the previous input, "hello", and lost the input I was working on.

---

Here the function is pretty simple and you might say "don't hit the arrow key 3 times !", but if you are writing a longer function, with multiple line break and want to navigate to the top, this can happen (I was definitely bitten by that multiple times over the years).

I'm not sure what the expected result should be, but we should not lose what the user was typing. We may have Ctrl/Cmd + Z display the last "edited" input, or have a dedicated "history navigation" mode where we don't put the history item in the JsTerm (and then tab/enter would put the item in the input). It might work well with the reverse-history search we plan to work on

Comment 1

[Nicolas Chevobbe [:nchevobbe]]

Note that we save the last entered input, so user can get it back by navigating down. I don't think people realize that so we should make it more obvious

Comment 2

[Szmozsánszky István [:flaki]]

I'm only familiar with the Linux/Bash way of doing things but there history edits are all preserved (of which, "currently edited" line is just one, the latest).

In my usecase, hitting (up) at 3) and rewriting hello with the code in 3), then accidentally hitting the down key one too many times would take me to an empty prompt. Hitting up again wouldn't take me to my edited code (on latest Nightly at least), but would show "hello" again. In Linux/Bash my previous edits would have been preserved and I could continue from where I left off.

Comment 3

[Florens Verschelde :fvsch]

I have another STR scenario:

1. Write 'Item 1', hit Enter.
2. Write 'Item 2', hit Enter.
3. Hit the Up key. The editor now shows 'Item 2'.
4. Modify the current input so that it shows 'Item 2, modified'.
5. Hit the Up key again. The editor now shows 'Item 1'.
6. Hit the Down key. The editor shows 'Item 2'.
7. Hit the Down key. The editor is now empty.

In the scenario, the input 'Item 2, modified' was lost.
So if you’re editing an history entry, you lose that modified input as soon as you navigate away from it (up or down).

This probably explains why, from experience, I don’t trust that the Console can retrieve my input if I accidentally hit the Up key. It works in some conditions, but not in the one I described, and I must be running into it often enough to just remember "damn, I lost what I was writing, for good". ^^

One solution would be to "fork" the history entry as soon as it's modified. That means having a composite history with both "sent" and "unsent" items. Schematically:

0: 'Item 1', sent
1: 'Item 2', sent
2: 'Some other input', unsent, current

If I go back to 1, and start modifying it:

0: 'Item 1', sent
1: 'Item 2', sent
2: 'Item 2 modified', unsent, current
3: 'Some other input', unsent

From there, I can up then down, or down then up, and still retrieve 'Item 2 modified'. Nothing is lost.

The downside is that it could spam the history with a lot of barely modified content, like edits with a space added at the end, that kind of thing. In those cases, it could become more confusing than helpful.

So another option would be to overwrite the history item with the user's edits:

0: 'Item 1', sent
1: 'Item 2 modified', sent-then-modified, current
2: 'Some other input', unsent

If that can be combined with editor history (Ctrl|Cmd+Z) so that users can retrieve the initial value of item #1, then it’s perfect. (Could be awful to implement, I don’t know.)

Comment 4

[Florens Verschelde :fvsch]

That’s the one complete data loss I could find, not sure if there are others.

Then there is the usability issue of users accidentally going back in history and *thinking* they lost their input, even in cases where that input is actually saved and can be retrieved (using the down key enough times).

I think the big UX issue here is that the Console tries to mix to patterns:
- The shell pattern, like Bash, where Up/Down is exclusively for navigating in history.
- The multi-line editor pattern, like any text editor, where Up/Down is for navigating in the current input.

The Console is a bit unpredictable here. For a single line and 3 different cursor positions:

1: '|hello'
2. 'hell|o'
3. 'hello|'

The "Up" key will go back in history for #1 (expected) and #3 (a bit of a surprise!!). For #2, it will put the cursor at the start of the line.
I believe the difference in behavior between #2 and #3 is tripping up users, and creating frustration.
(Chrome's Console has slightly different heuristics, but they’re not particularly better. For instance in multiline text, with the cursor at the end of the first line, "Up" goes back in history. Firefox treats this case as a #2: cursor in the middle of the input.)

At the very least, I think this behavior should be changed, and #3 should act like #2.
Currently the logic seems to be "cursor is at a edge, so both Up and Down trigger history navigation". The logic should be split in two: "Cursor is at the start edge, so Up can go back in history" + "Cursor is at the end edge, so Down can go forward in history".

This doesn’t fix the "mix of two patterns" issue, but it makes this mix more predictable (instead of semi-random).

A more radical fix would be to use two different keyboard shortcuts:

1. Reserve Up/Down for navigating in the current input. Never trigger history.
2. Use something else for history navigation, maybe Alt+Up and Alt+Down.

Changing this would probably require some UI work to alert users that the shortcuts changed.

Comment 5

[Florens Verschelde :fvsch]

Just realized that when the cursor it at the end, you need both Up and Down to navigate history, otherwise you can't explore history with quick successions like "up-up-up-up-down". So I guess this can't be changed at all. :/

So, for possible UX changes:

## Changing the keyboard shortcuts

Protects users who are not used to history and don’t rely on it. For others, they probably should be warned, e.g. if they hit the Up or Down key twice in a row when the cursor is at an edge: maybe print a message with instructions? And maybe make it an option for users who want shell-like history navigation (with up/down)?

## Differing selection of history entries

Alternatively, the up/down shortcuts could be kept as-is, but instead of changing the content of the main input it would show history entries as an overlay, and require user action a click or maybe the Right key or Enter to select and entry and fill the input with it. This could be used to surface the "search history" feature too. Basically, an experience more like Sublime Text/Atom/VS Code than like Bash.

Comment 6

[Florens Verschelde :fvsch]

Attachment: quick-mockup-console-history-overlay.png

So I did a "quick" mockup of a Console history overlay.

The idea, which is just food for thought, is that it could work on top of the current behavior, so that when users trigger history navigation it’s much more perceptible. It would also make some actions more directly perceptible:

1. Cancel history navigation: close button, maybe Esc key too (common for modals).
2. Explore history visually, through scrolling or using the arrow keys.
3. Search history.

Of course this might be overkill for console history.

Comment 7

[Nicolas Chevobbe [:nchevobbe]]

(In reply to Florens Verschelde from comment #6)
> Created attachment 8997507 [details]
> quick-mockup-console-history-overlay.png
> 
> So I did a "quick" mockup of a Console history overlay.
> 
> The idea, which is just food for thought, is that it could work on top of
> the current behavior, so that when users trigger history navigation it’s
> much more perceptible. It would also make some actions more directly
> perceptible:
> 
> 1. Cancel history navigation: close button, maybe Esc key too (common for
> modals).
> 2. Explore history visually, through scrolling or using the arrow keys.
> 3. Search history.
> 
> Of course this might be overkill for console history.

Thanks for the mockup Florens, that's interesting. We are also working on history reverse search (see Bug 1024913 - there's a patch you can try), but this looked more like a bash thing.
The "Palette" you are suggesting would also make sense.
I'm a bit concerned showing a big overlay like this when the user hit arrow up as it may feel a bit jarring.
Also, it would be nice to see how this would play with a toolbox-wide command palette