Do not persist unsaved, non-navigational state from URL

[epixa]

The amount of state that we store in URLs is increasingly becoming a problem as Kibana becomes more complex.

All supported browsers have URL length limits which can be hit under real world conditions. IE11 and Edge have URL length limits that are borderline trivial to hit under real world conditions. We've created an opt-in feature to store state in session storage to help address this problem for those that are most likely to encounter it, but that feature results in an awkward experience since the normal use case of sharing your current URL is no longer possible without resulting to the short URL service.

The short URL service has no way to clean up after itself since you can create a short URL about absolutely any state of the UI that you could possibly want, so there's no reasonable way to determine whether a given short URL is even still usable.

Complex features like X-Pack graph essentially cannot track state in the same way that the rest of Kibana does because there is too much data to serialize in a URL, so the experience of using graph is unexpected and inconsistent.

We should change the way we handle state so that the only state we put in the URL is data that is related to navigation throughout the entire Kibana application (e.g. currently loaded object id, current Kibana application, etc). State related to changes made in the current application should be persisted specific to that user or session based on the needs of the application.

Some examples:

• Console stores previously run queries in localstorage so they load up again in the future.
• Visualize stores the current aggregation details as you're building or editing a visualization in session storage, so the choices you make are persisted if you refresh the page but are lost if you close your browser without saving.

[epixa]

/cc @stacey-gammon @uboness @alexfrancoeur

[trevan]

Timespan and filters should still be in the url so that if I share a dashboard with someone, they should see the same timespan/filters that I added to it. I don't want to store this timespan and filters to the dashboard.

And since lots of filters could hit the url limit, either those need to be shortened or some other mechanism needs to exits to allow sharing.

[epixa]

@trevan To be honest, I think what you just said is exactly what this ticket is proposing changing. The use case you just described is totally valid though, so it is important for us to consider possible features to make that doable.

Would the ability to create and share a new dashboard in a single click based on the state of the current dashboard you're looking at work in your case?

I don't have a solution to this problem yet, so that's just one idea.

[stacey-gammon]

@trevan, something that complements this issue that we have also been talking about is auto-save. While I see your point about the timespan, because that might not be saved with a dashboard, filters are always stored with a dashboard.

What are your thoughts on a auto-save feature? If as you added/removed filters they were automatically stored with your dashboard?

I don't want to completely disrail the conversation off the original topic (autosave should probably have it's own issue), but I'm curious on your thoughts.

[trevan]

@epixa, when you say "create and share", is that saving a brand new dashboard? I'd rather not have that.

When I'm sharing these links, they are ephemeral.

Take an example where I and several other engineers are trying to figure out why our system is dying. We are all on Skype and talking about different ideas while at the same time trying to prove/disprove each of the ideas. This involves doing discovery searches, visualizations, and dashboards. I might take an existing visualization, edit it, add filters, change the time range, and then share what I found. Then continue changing the visualization or going on to a completely different one.

Saving feels "permanent". I save when I want to keep what I did. Sometimes, I do save what I shared if I found it useful for a high level view. But most of the time, it is used once and never used again.

@stacey-gammon, I would strongly dislike an auto-save feature in my normal use case.

I think the best way to explain is that Kibana has three modes (in my mind): display, edit, investigate.

The display mode is where I want to show it on a big screen, present it to other people, print it out, etc. In this mode, I might change the time range but I'll never do filters.

The edit mode is where I'm creating things for the display mode. I'm preparing a big screen dashboard, preparing for a presentation, etc. In this mode, the auto-save could be useful.

The investigate mode is where I'm trying to understand what is happening in my data. We use elasticsearch for security (kind of like a SIEM) and so I'm in this mode far more often. I take existing dashboards/visualizations/searches and add filters (global filters as we made that the default), change time spans, completely rebuild the visualization, bounce between the different areas, etc. I would hate for my changes to be auto-saved. My saved visualizations/dashboards/searches are starting points to finding things. They give me a nice high level view of things. Auto saving them would completely ruin them.

One idea is something that I saw at another company I used to work for. They would add a "state id" to all the urls. The actual state would be saved in a database that is shared between all users. This allowed small urls as well as easy sharing of urls. The state id would only last a few days long so you had to save anything you wanted more permanently.

[volter]

All supported browsers have URL length limits which can be hit under real world conditions.

There's actually another problem too: The Location header of the 302 response can be cut off, leaving clients with a fraction of the URL. In particular Apache's mod_proxy module seems to have a hard-coded 8 kB limit.

https://serverfault.com/questions/711750/apache-2-4-16-response-header-value-clipped indicates that this might be a permanent problem.