[discuss] Deprecate state:storeInSessionStorage?

[Dosant]

Shall we consider deprecating and removing state:storeInSessionStorage advanced setting?
My understanding is that it was primarily needed to workaround IE url limit?
Please let me know if this is not the only use case and there are still benefits for keeping this around past IE support.

From the description:

The URL can sometimes grow to be too large for some browsers to handle.
To counter-act this we are testing if storing parts of the URL in session storage could help. 
Please let us know how it goes!

Please note:

• This option is disabled by default.
• Not sure if we have insight into usage?
• Only kibana apps use it. Other apps doesn't implement this setting.
• Initially this was brought up as part of the discussion around uiSettings ownership [uiSettings]: Migrate items owned by app arch to new platform #66040 (comment). Most of the code that implements hashing is in kibana_utils, but seemed weird that an advanced setting would belong to utils plugin.

If we remove this we could get rid of pretty complex codepaths and increase tests code coverage:

• https://github.com/elastic/kibana/tree/master/src/plugins/kibana_utils/public/state_management/state_hash
• https://github.com/elastic/kibana/tree/master/src/plugins/kibana_utils/public/storage/hashed_item_store
• There also was a special plugin to handle short url edge cases, which I can't find right now 🤔 old code (Maybe we have some regressions in that area?)
• Probably url_overflow code could be removed as well src/legacy/ui/public/error_url_overflow?

Questions

1. This was needed only to workaround IE url limitation? Is this correct?
2. If yes, should we consider deprecating it in post IE era?
3. If yes, do we have to wait for 8.0 to remove it?

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[elasticmachine]

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

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[timroes]

This was needed only to workaround IE url limitation? Is this correct?

And the answer here is: No. And thus unfortunately solve all the other questions already. In general it's used to handle too long URLs. This is not an IE11 problem, IE just have a significant lower limit, so you can run way easier into that. But since we store the full state inside the URL you can run into rather long URLs. One example where this might happen (also in other browser) more regularily, is if you try to use Vega and writing long Specifications, which we'll then store fully in the URL. So you might need to use that setting for writing Vega. Ideally we would have a good way, not to store thus kind of long state in the URL, and always store it separately, but I think that'll require quiet some changes to the visualize editor, to have "back" still working as expected, etc. (see also #17603).

[Dosant]

Got it, @timroes, thanks for detailed explanation!

[LeeDr]

The other case I ran into where state:storeInSessionStorage was required was when I had a very large scripted field and tried to use that value (in a filter control) on a dashboard. The entire scripted field was in the URL.