Console ESC prompt can be annoying

[pmusa]

I have been using console version that has the ESC key prompt for the last days and it is very annoying. I understand it provides keyboard-accessibility, but it would be nice to have an option to disable it if not needed. Moreover, the current implementation prompts if you press the ESC key to escape auto-complete which makes it even worse. Maybe we can use this issue to discuss other possibilities that guarantee keyboard-accessibility without annoying other users.

[mikeprince3]

@pmusa if you referring to how the screen will white-out and display the "Press Enter to start editing. When you're done, press Escape to stop editing" message, then I completely agree. It appears that I formed a habit (prior to Kibana) where I use ESC to dismiss any unwanted auto-complete prompts. I get that I can just keep typing and ignore it, in the case of Kibana, but my pre-existing condition leads to me see the white-out message almost constantly. It's a bit maddening for me.

[rseniuta]

The docs say that ESC "Close auto-complete menu." but it does not, it frozes screen and display prompt first.

[fmad]

I would give this 1000 votes if I could! It's so annoying when I try to cancel some auto-complete! Please revert this back to how it was before! Luckily, I've only been using this new version in training, but we'll be upgrading to 6.x soon, so it will become a BIG nuisance!

[cjcenizal]

Sorry to everyone who's been frustrated by this! This should be fixed in the next patch release across the board.

[hackery]

It still does it in 7.x.

[cjcenizal]

@hackery Which specific version are you using and can you describe the precise behavior you're seeing?

Here is what I see on master, which is the behavior I expect. Hitting ESC once will dismiss the autocomplete menu, and then if you hit ESC a second time focus is exited from the editor.

[pmusa]

It has been working fine for me as well.

[hackery]

You're right, I can't reproduce this today. Perhaps I was getting some key bounce on ESC.
I'll take my zombie thread bronze star and get my coat ...

[hackery]

I take it back, I'm not seeing things: in our QA environment I see the behaviour you're expecting, and in Production I see the focus loss on a single escape when the autocompletion menu is up. Both are running the same 7.1.1 release.

[cjcenizal]

@hackery Because other people can produce the correct behavior and because you can produce the correct behavior on one environment but not another, I suspect there may be some factor in your production environment (or perhaps something machine- or browser-specific when you visit your production environment) that's causing this unexpected behavior.

Could you try asking a coworker to reproduce the bug on another machine? Could you try reproducing the bug on in incognito mode and on different browsers? Thanks!

[hackery]

OK - today I've seen it on our QA env as well - in the same browser session/tab that I had open yesterday and didn't see it. I see correct behaviour in both environments if I open an incognito window, or even a new regular browser tab in the same window. Exiting browser and restarting (with tabs automatically restored) it works as well.

If I switch features within the Kibana plugin (Discover, Visualize, Dashboard etc) and back, the behaviour remains. If I switch to a feature from a different plugin (e.g. Monitoring) it reverts to correct behaviour. I'm presuming there's some specific user activity over time within devtools which triggers this state. I often leave a tab open for days, switching between features as needed; at the moment I'm trying to trace down a performance problem and have several tabs open on different features to speed navigation, so perhaps my devtools tab has been open longer than typical without switching plugins.

So, it might still be browser-specific. Our prod environment is quite restrictive and only has Chrome, so I can't easily make comparisons there, but on my dev machine I have Chrome 76.0, FF and Vivaldi I can try. In the meantime, I'll try and watch for what I might be doing before the bug appears.

[cjcenizal]

Wow, this is some great info. Very strange indeed. Have you tried clearing your cache? I wonder if there's some weird caching problem happening.

In the meantime, I'll try and watch for what I might be doing before the bug appears.

Any info you can dig up here would go a long way towards helping us reproduce this. Thanks again for reporting this bug and looking so deeply into it!

[hackery]

Well, I could do a cache clear, but that would only take effect on a page reload, which by itself gets back to the proper behaviour anyway.

Possible clue: I noticed this while Chrome DevTools was up:
mapping size is larger than 10MB (35.470909118652344 MB). ignoring..
which looks like it's in this handler for retrieval of autocompletion names from ES. I don't see any obviously problematic code path there but I'm not too familiar with this code - but it seems to be in an applicable bit of functionality.

[mikeprince3]

Maybe we can use this issue to discuss other possibilities that guarantee keyboard-accessibility without annoying other users.

This is one part from the original post that seems to have been dropped from the conversation. It would be amazing if the "Press Enter to start editing. When you’re done, press Escape to stop editing." prompt could be disabled in the settings. It wasn't clear until I read this post why it even existed.

[cjcenizal]

@mikeprince3 You're right, thank you for bringing that up again. I'm going to reopen this so we can look into ways to resolving this. For example, in this Monaco issue they suggest using an unobtrusive tooltip.

[elasticmachine]

Pinging @elastic/es-ui

[Ahnfelt]

It still happens in 8.5.0 for me (Firefox 108.0.1 on macOS).

I can reproduce this without entering a single character, but just using the arrow keys to move to some point where the suggestions show up*.

When I press escape at that point, the editor locks and displays the "Press Enter to start editing.
When you’re done, press Escape to stop editing.".

• Is this expected behavior? In other editors I've tried, auto completions don't come up when you just use the arrow keys - you normally need to type something. And for good reason - it takes over the arrow keys, so you can't move past it! And then you press escape, and the whole editor locks...

[yuliacech]

I've been trying to reproduce this issue and on version 8.7.0 the ESC overlay can't exited by pressing the ESC button again. That means the focus is trapped inside the editor area and it breaks the keyboard navigation around the Console. I'll be looking into fixing this first.
The other issue was pressing ESC to close the autocomplete suggestions: this one I was not able to reproduce. The expected behaviour is: when autocomplete suggestions are open, ESC will close the autocomplete suggestions. If autocomplete suggestions are not open, ESC will display the a11y overlay. I tested this on v8.7. with Firefox/macos and it works as expected for me. @Ahnfelt could you please try to reproduce this issue with an 8.7.0 deployment and if possible upload a screen recording and steps to reproduce?
And the last issue I want to look into is if there are alternative ways to allow accessible keyboard navigation out of the editor area.

[fmad]

Why is there even a need to disable the keyboard by pressing ESC? What is the use case for that? As all it takes, with or without bug, is to press ESC one too many times and then you're stuck typing in limbo until you look at the screen again and press enter - it doesn't happen to me often, but it is SO annoying when it does.

[ccaspanello]

I am seeing this issue on the 8.7.1 Docker Images:

docker network create elastic
docker pull docker.elastic.co/elasticsearch/elasticsearch:8.7.1
docker run --name elasticsearch --net elastic -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" -t docker.elastic.co/elasticsearch/elasticsearch:8.7.1

docker pull docker.elastic.co/kibana/kibana:8.7.1
docker -d run --name kibana --net elastic -p 5601:5601 docker.elastic.co/kibana/kibana:8.7.1

[yuliacech]

I looked more into this issue and the current behaviour is expected: When typing in the editor area, pressing the ESC button allows the user to navigate away by pressing TAB. This is important for accessibility because otherwise it's not possible to navigate away from the editor area by only using the keyboard.

[hackery]

That just begs the question, what's the use case for supporting TAB in the console editor? The auto-indent works just fine, and if you wreck the indenting yourself, space-space gives you a tab stop. Most (many?) web UI interfaces tab away from input fields (even multi-line), inserting a tab is usually the hard thing to do.

[yuliacech]

This behaviour is used in other editors in Kibana, so I'd prefer to keep it consistent.

[mikeprince3]

@yuliacech I understand the value and neccessity of supporting accessbility requirements. However, can a switch be added to disable this feature in the editor (or for all editors given the understandable preference for consistency)? Perhaps on the ESC popup screen there could be a switch to disable the feature?

[fmad]

Just managed to repro this as sometimes it is a bit hit-and-miss = If I move away from the window and come back and click on something that then causes a popup, say GET or an index name or something similar, my immediate reaction is to press ESC, at which time this bug happens and I'm "stuck" to have to then press ENTER, which usually means abandoning the mouse to use that hand for that (I'm right-handed). At least, make it so that pressing ESC again would cancel that, so I could just ESCape out of that...

[mikeprince3]

I'm not sure what the ettiquette is around commenting on a closed ticket but thank you so much for adding this setting @yuliacech !

[yuliacech]

Thanks a lot everyone for commenting on this issue and providing repro steps! I was not able to reliably reproduce the issue and went with @mikeprince3's suggestion of adding a setting that disables the overlay. Thanks for the suggestion @mikeprince3