Menu tree state flaky when working in multiple tabs

I (along with my coworkers) have been experiencing numerous frustrating menu tree-related problems - mostly with the resource tree. I'm going to try to pay closer attention and track down some of the specific issues that are happening. Here's one I've pinpointed so far.

The issue, as best as I can tell, is this: When loading/reloading a Manager page, the question of "Which tree panel is displayed?" is answered by "Whichever panel's *tab* was clicked on last", rather than "whichever panel an *item* was clicked on in last".

This can get very disorienting when multiple tabs are being used. Consider:

• I have one tab open for editing a Resource. My resource tree is being displayed.
• I open a second tab to edit a chunk. I click on the Elements tab to find the chunk, and begin editing it.
• A few moments later, I'm back in the first tab editing the Resource. I save, and click on another Resource in the tree.

My expectation as a user is that when I have clicked on a resource to edit it, when the page loads I am going to see the Resource tree. But in the above scenario, this is not the case. When the new "edit resource" page loads, it will display the Elements tree. Why? Because that was the last tree *tab* that I clicked on in this browser session in any browser session while logged in as the current user.

Go on, try it. I'll wait.

I've replicated this in Chrome & Firefox on Windows 8 and OS X. I don't think it is browser/platform specific. It seems pretty clear that the tree panel that opens is always the one which last had it's tab clicked on in the current session any browser session logged in to manager as the current user.

In the short time I've been experimenting since the lightbulb went off and I figured out how to replicate this, I've seen further weirdness at least once: I clicked on a different resource in the resource tree, the page came back with the Elements tab displayed (because that was the last tab I'd clicked on, in a different tab or session), but no elements were visible in the elements tree (not even the names of the element types) and the refresh button on the elements tab didn't work. I had to reload the page in the browser to see the tree. (This is akin to some of the other vague weirdness I've been seeing with the tree panel, but I can't easily replicate it so I'm just making a note of it for now).

Anyway, it seems to me that a whole lot of unsettling user experience could be avoided simply by answering the question "Which tree panel is displayed?" with "Whichever one an *item* was clicked on in last". Does anyone else care to weigh in on this? I'd love to hear your experiences and opinions. I can't be the only one who's had this problem.

This is by design (tho if it's the best design from a user experience perspective, it might not be so): when you click a tab, it fires of an ajax request to store your "state"; ie what you are viewing. When using multiple browser tabs, that can be confusing. There's also a slight delay between clicking a tab and the state being stored.

That's kind of what I figured.

Could the same ajax request be fired when a user clicks on an *item* in the open tree? That would largely solve the problem in this situation. The only scenario I can think of that it wouldn't fix would be if you reloaded a page in the browser - the tree display might still change in that case.

Bane of my life this is.... That and the file browser not opening to the correct media source. Grr.

Few potential pull requests I came up with when I first started using MODX are somewhat based off this:

• Tree has a 'lock button' that caches the tree, maybe up to x minutes
• A way to launch a modal window that is basically Spotlight for looking up Elements
• Expand all on Element types and categories, not just on the whole tree

Maybe I'm crazy, but wouldn't it make sense to determine which tree to show based simply on the action? If editing a resource, show the resource tree, if editing an element, show the element tree, etc.? Determine the tree state by a simple switch statement on the 'a' value from the query string?

I can't for the life of me think of a circumstance when I'd initiate editing or creating a resource and WANT the initial state of the tree panel to show me the File or Element tree.

Just thinking out loud here.

My solution is to avoid page reloading. You can try AjaxManager extra, but this has some problems with third-party extras. There is no 100% guarantee of good experience with AjaxManager

Quote from: jrotering at Feb 20, 2013, 07:33 PM

I can't for the life of me think of a circumstance when I'd initiate editing or creating a resource and WANT the initial state of the tree panel to show me the File or Element tree.

I do it all the time, because I can't remember what I named my chunks, snippets and TVs. And I often need to look at the Resource tree when working with elements to get the ID of a resource.

Quote from: sottwell at Feb 20, 2013, 08:06 PM

I do it all the time, because I can't remember what I named my chunks, snippets and TVs. And I often need to look at the Resource tree when working with elements to get the ID of a resource.

I do those things all the time too Susan. Being able to "tab over" to the elements tree to find the name of a chunk (for example) is a necessity. But what I'm asking is, is there ever a case where you need/want the *initial* state of the tree panel to be focused on that other tree? As in, I'm now going to click on resource #326 to edit it, and when the manager page loads, I want it to show me the Element panel? I can't see where that would ever be desirable.

The tree(s) should exist in its entirety, just not get in its own way so much