Commit 1574eb5
committed
Attempt to solve timeout issue when loading legacy visualizations dashboard (#271948)
Closes #271816
## Summary
### Theory
[#271520](#271520) exposed the
issue because it changed the timing of FTR’s first authenticated
navigation.
Before that PR, common.navigateToApp('dashboards') hit the login page,
filled the UI form, waited for Kibana chrome, then navigated to the app
URL again. That slower, multi-step flow gave the Dashboards app more
time to settle on #/list before the next call to
loadDashboardInEditMode().
After that PR, login is done by API and cookie injection.
loginIfPrompted() now injects the sid cookie and navigates directly to
the target app URL. That is faster and skips some of the old UI-login
waits. So the test reaches:
```
dashboard.initTests() -> dashboard.loadDashboardInEditMode() -> gotoDashboardLandingPage()
```
sooner, while the Dashboards route can still be settling.
The underlying bug was already in gotoDashboardLandingPage(): it checks
the URL once, and if it does not see dashboards#/list at that exact
moment, it assumes it must be inside a dashboard and waits for the
in-dashboard breadcrumb.
(cherry picked from commit 5ed988c)1 parent 0efcb0e commit 1574eb5
1 file changed
Lines changed: 3 additions & 3 deletions
Lines changed: 3 additions & 3 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
20 | 20 | | |
21 | 21 | | |
22 | 22 | | |
23 | | - | |
| 23 | + | |
24 | 24 | | |
25 | 25 | | |
26 | 26 | | |
27 | 27 | | |
28 | 28 | | |
29 | | - | |
30 | | - | |
| 29 | + | |
31 | 30 | | |
32 | 31 | | |
| 32 | + | |
33 | 33 | | |
34 | 34 | | |
35 | 35 | | |
| |||
0 commit comments