Navigation menu item is not highlighted if navigating to solutions from the Kibana home page

[hendry-lim]

Kibana version: 7.10.0-SNAPSHOT

Elasticsearch version: 7.10.0-SNAPSHOT

Original install method (e.g. download page, yum, from source, etc.): Docker

Describe the bug:
Navigating to Enterprise Search, Observability, Security from the Kibana home page does not highlight the navigation menu item on the left.

Steps to reproduce:

1. In Kibana home page, click either Enterprise Search, Observability, or Security
2. Observe the menu item on the left navigation is not highlighted

Expected behavior:
Selected navigation menu item should be highlighted as if navigating via the menu item.

Screenshots (if relevant):

gif

[elasticmachine]

Pinging @elastic/kibana-core-ui (Team:Core UI)

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[pgayvallet]

When navigating from the home to entrepriseSearch, I can see that application.currentAppId$ is emitting two different values: enterpriseSearch, then enterprise_search. The correct one, as registered by the plugin, is the first one: enterpriseSearch.

The second value is wrong, and causes this check

kibana/src/core/public/chrome/ui/header/nav_link.tsx

Line 74 in 7df0b34

isActive: appId === id,

to be falsy.

When navigating using the navigation menu, It's behaving as expected by only emitting enterpriseSearch

The same thing occurs with observability and security.

Seems like a bug in the ApplicationService for app with an ID and a custom appRoute that don't match. We are probably using the route's id parameter instead of the actual app registered ID somewhere.

e.g for enterprise search: ID: 'enterpriseSearch', and URL: '/app/enterprise_search/overview',

[pgayvallet]

After further investigations, it's a mix of two things:

1. Root cause: the way home is redirecting to the solution apps is based on url parsing and a call to navigateToApp

kibana/src/plugins/home/public/application/components/app_navigation_handler.ts

Lines 23 to 29 in 532f2d7

	export const createAppNavigationHandler = (targetUrl: string) => (event: MouseEvent) => {
	if (event.altKey || event.metaKey || event.ctrlKey) {
	return;
	}
	if (targetUrl.startsWith('/app/')) {
	const [, appId, path] = /\/app\/(.*?)((\/|\?|#|$).*)/.exec(targetUrl) || [];
	if (!appId) {

This is wrong on two levels:

• it uses the wrong ID, as it parses it from the url, which doesn't work with custom routes (enterprise_search instead of enterpriseSearch)
• it doesn't work with apps with custom routes not starting with /app/

2. application.navigateToApp does not checks if the given appId is a valid one, as we decided to still redirect to the app's route to let the AppRoute component display the 404 pages. When the appId is invalid, but /app/(appId} is the route of a valid app, it's just displaying the app, while emitting an invalid appId with currentAppId$. This is what is happening with the enterpriseSearch id vs the /app/enterprise_search route.

Changing navigateToApp behavior would require to rethink our whole routing mechanism, which seems way too impactful. I'm going to just fix home's createAppNavigationHandler instead.