Kibana: Discover New button takes forever or doesn't work

[LeeDr]

Kibana version: master, and 7.4.0

Elasticsearch version: master, and 7.4.0

Server OS version: Windows, Ubuntu 18

Browser version: Chrome, Firefox

Browser OS version: Windows 10

Original install method (e.g. download page, yum, from source, etc.): Source for master, snapshot zip files for 7.4.0

Describe the bug: The New button in Discover doesn't immediately work. It should return to a new search and set back to the default index. It seems like it eventually does do that, but it might take 10 seconds and/or moving the mouse around the discover tab may be triggering it.

Steps to reproduce:

1. have 2 or more index patterns (you can include system indices and use .kibana* and .kib*)
2. go to discover and select a non-default index pattern
3. click New menu item. Notice the focus highlighting stays on the button until eventually the index pattern changes to the default and focus moves to the query bar.

Expected behavior:

Screenshots (if relevant):

Errors in browser console (if relevant):

Provide logs and/or server output (if relevant):

Any additional context:

[elasticmachine]

Pinging @elastic/kibana-app

[LeeDr]

I just installed the latest 7.3.2 BC build which is essentially what we just released 2 days ago and I could not reproduce the problem there. So it's something between 7.3.2 and 7.4.0.

[chandlerprall]

Looks like this one's something related to React+Angular mixing - I mapped the following with Chrome's performance recording

• I clicked on discovery's New button, I see the react handler kick off for ~25ms during which it calls handleClick from top_nav_menu_item.tsx
• no updates in the page UI
• I move my cursor over the index selection box which triggers a tooltip and immediately starts the page navigation, this includes a 1.09s handler triggered from a timer, Browser.self.defer @ angular.js:6705. This eventually executes onRouteChange from sub_url_hooks.js

This same order of events can be triggered by clicking the New button and then tabbing until focus reaches the index select box, at which point the same Angular timer and digest fires.

[kertal]

So, the click on new runs the following code, there should be a change of URL to /discover, but it works only sometimes:
https://github.com/elastic/kibana/blob/73ef1cb52ec64c43c2a7fc0b3bfddcd165aa21db/src/legacy/core_plugins/kibana/public/discover/controllers/discover.js#L259

[flash1293]

I have a few functional test failures in Graph (e.g. https://github.com/elastic/kibana/issues/45317 ) that might be caused by the same thing - it's also using the top nav but in functional tests the action is not triggered in some cases (even though the html button click works). I also noticed that url changes triggered by the top nav have a noticeable delay in Graph.

[elasticmachine]

Pinging @elastic/kibana-app-arch

[flash1293]

@kertal I think I found the problem with that one - kbnUrl.change triggers this logic: https://github.com/elastic/kibana/blob/master/src/legacy/ui/public/url/url.js#L215

But the route change (and thus the reload call) is only triggered if it happens in an angular digest cycle (I thought $location.change takes care of this, but apparently doesn't).

Wrapping the call into an $evalAsync seems to solve the problem:

run: function () { $scope.$evalAysnc(() => { kbnUrl.change('/discover'); }); },

[kertal]

@flash1293 works! you're ⚡️!

[timroes]

I think this qualifies as a blocker, @LeeDr ?