Redirect to full path when calling navigateToApp to a legacy app

[joshdover]

Summary

This fixes a bug where calling navigateToApp from a KP application to redirect to a legacy application would result in the path being lost.

This was happening because the "mounter" constructed for legacy applications always redirected to the legacy app's base route rather than the path that was specified in the navigateToApp call.

Dev Docs

A bug was fixed where calling core.application.navigateToApp to a legacy application would not retain the path specified.

Checklist

Delete any items that are not applicable to this PR.

• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for cross-browser compatibility, including a check against IE11

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

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

[joshdover]

Clearly this has broken some things. Putting back into draft.

[flash1293]

I haven't tested the PR, but at least the spaces error (ci group 4) could be caused by the fact that now, if navigateToApp is used in the legacy platform to go to the legacy platform, the page is always reloaded, even if it's the same legacy app.

That wasn't the case before, because if the user is on app/kibana#/discover and navigateToApp('kibana', { path: '#/management/spaces' }) is called, it would just do a hash change, not a reload. I think the test fails because it assumes this navigation is fast - the error screenshot shows the regular Kibana loading spinner. It should be enough to check whether the app actually changes by the navigateToApp call and only call window.location.reload(); when that's the case.

[joshdover]

I haven't tested the PR, but at least the spaces error (ci group 4) could be caused by the fact that now, if navigateToApp is used in the legacy platform to go to the legacy platform, the page is always reloaded, even if it's the same legacy app.

That wasn't the case before, because if the user is on app/kibana#/discover and navigateToApp('kibana', { path: '#/management/spaces' }) is called, it would just do a hash change, not a reload. I think the test fails because it assumes this navigation is fast - the error screenshot shows the regular Kibana loading spinner. It should be enough to check whether the app actually changes by the navigateToApp call and only call window.location.reload(); when that's the case.

Yep you are right 😄 I will have to think of a different solution. Honestly how this was originally implemented was better since it did not require this sort of loopback from history -> router -> app container -> legacy "mounter"

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 76600a4

History

• 💔 Build #45124 failed 2e7df63733429db1e85bc237d5885c8e161e81f5

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[flash1293]

Tested in Chrome - the "Manage spaces" button works fine with this PR and just redirects to home without it when clicked on a new platform app. LGTM

No thorough code review

[pgayvallet]

LGTM