Keep status of expanded tree when navigating back in browser

[svenseeberg]

Motivation

When opening a page for navigation in browser, the state of the tree should be kept (which parts of the tree are expanded/collapsed).

Proposed Solution

Track the status of the tree in a Cookie(?) and automatically expand the tree as needed/set.

Alternatives

Make it work in the browser history, which we disabled.

Additional Context

We intentionally disabled browser cache right now.

[timobrembeck]

So #1179 was actually a feature and not a bug? :laughing:

[timobrembeck]

Why would we need a cookie for this? Can't we just revert the changes from #1192?

[svenseeberg]

There were actually bugs which we solved with #1192: When using the back button after a search, the tree was fully expanded instead of keeping the state. Also dragging and dropping was broken after going back.

Regarding this issue: if the solution is very complicated, we should and can discuss the priority. But it would be very nice to have it soon.

[svenseeberg]

https://developer.mozilla.org/en-US/docs/Web/API/History_API

[timobrembeck]

@svenseeberg but I guess the normal history API is also used on the back button? If the tree is broken after using the back-button, I see no reason why it should work using window.history.back(). But maybe I'm missing something :sweat_smile:

[svenseeberg]

@timoludwig I was thinking that we can maybe fix things by pushing states to the history whenever we're firing AJAX calls. But that is quite a lot of effort. That means we need to implement functions that redo/undo changes to the page tree. Redoing things is probably easy, as we just need to store the result of the AJAX call and fire the same(?) functions again. However doing it in reverse is probably quite different. The brute method could be to actually store the fully rendered HTML/DOM tree in the history and replace the content of the containing element?!

[timobrembeck]

I enabled the browser cache of the page tree again in 0e2b49c2db6de28bfc01027ca541748ff6920aa7, but this does not lead to the tree being expanded on the back button. So apparently, the source of bug #1179 was not the browser cache, but something different, and removing the browser cache just was a workaround.

Regarding this issue: Yes, your approach makes sense, but is definitely not an easy task. With all our event handlers, this increases the potential for bugs which we cannot prevent with unit tests. Maybe the latest improvements to the page tree already provide most of the functionality that was the motivation of this issue?

[svenseeberg]

I think we should keep the scope of this issue limited to storing the expanded/collapsed state of single nodes. And this info could easily stored in a cookie. That means we do not have a history of expand/collapse actions of the tree, but you can get back to the last state of the tree after changing a page translation. To my understanding this is the feature that editors are asking for.

[timobrembeck]

We could, yes. To me, it still sounds complicated and I'm not sure whether the benefit of the feature is big enough to justify the effort, but maybe I'm overestimating the complexity :wink:

[svenseeberg]

AFAICT we only need to keep a list of expanded page IDs in the cookie and call the existing expand JS function for each item after loading the tree view? Collapsing a node removes the ID from the list, expanding adds the ID.

We need to wait until all MPTT tree AJAX requests have finished, before we can start expanding the tree.