[TableListView] Listing page search ignores special characters without warning

[dej611]

Kibana version: 8.7.0 BC1

Describe the bug:

The Listing page seems to support also special characters search, but unsupported chars are not always documented correctly.

Example on unsupported special char and relative warning:

But using [ or ] leads to no results and no warning ( I've seen the [ some tag ] convention used something as dashboard names, even on sample data):

But there are dashboard with names containing the [ ... ] convention:

Adding a non-special char to the search box makes the search be performed correctly instead:

[elasticmachine]

Pinging @elastic/kibana-presentation (Team:Presentation)

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[sebelga]

The Listing page seems to support also special characters search, but unsupported chars are not always documented correctly.

I wonder how much on the EUI side this issue is and what we can actually do in Kibana. I'll have a look 👍

Adding a non-special char to the search box makes the search be performed correctly instead

@dej611 I'll look into it. I think we should require that at least 2 or 3 characters be inserted before triggering the search. Would that work?

[dej611]

As long as the user is hinted about adding more chars it's ok for me

[sebelga]

Looking at this issue to see how we can improve the search experience.

From what I understand from this PR elastic/eui#7175 we have a limitation on the chars allowed when doing an EQL query (with filters).
@cee-chen when I introduce a wrong char I don't get the toolip anymore when hovering the danger icon in the searchbar. Has it been removed on purpose or is this a regression? I'd like to know the exact list of chars that are not allowed to put them in a helptext underneath.

[cee-chen]

@cee-chen when I introduce a wrong char I don't get the toolip anymore when hovering the danger icon in the searchbar. Has it been removed on purpose or is this a regression?

There has never been a tooltip around error icons in EUI form controls - are you referring to the native browser title "tooltip"? If so, that is still there for me (see EUI example):

I'd like to know the exact list of chars that are not allowed to put them in a helptext underneath.

That's somewhat inferrable in the default_syntax PEG parser for EuiSearchBar here: https://github.com/elastic/eui/blob/54ab23a4d4bcdabb62f3b630f20fb7edaba874ee/packages/eui/src/components/search_bar/query/default_syntax.ts#L172-L176

Currently, any special character outside -_*@ are not allowed. Forward slashes are allowed and double backslashes are allowed.

This is actually a bit stricter than EQL necessitates, as the only characters that EQL explicitly requires for syntax purposes are ", (), : and \ (see elastic/eui#7160 (comment) and elastic/eui#6356).

If you feel strongly that the increased UX outweighs any potential bugs or crashes we might run into with EQL parsing, we could modify the default syntax parser to parse any character that is not the above characters as a word.

It is worth mentioning that the special characters in this issue description do work just fine with double quotes, so Kibana could theoretically also handle double quoting under the hood:

[sebelga]

Thanks for the input @cee-chen ! I ended up fixing this issue by hardcoding the list of forbidden characters and display hint when one is entered (#197307).

It is worth mentioning that the special characters in this issue description do work just fine with double quotes, so Kibana could theoretically also handle double quoting under the hood

That's good to know. Although it seems like that the parsing from the input element is immediately done by the EUI component and we get the error in the listener after.