Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 338152

Summary:	[client] Browser back does not return navigator tree to previously expanded state
Product:	[ECD] Orion	Reporter:	Andrew Niefer <aniefer>
Component:	Client	Assignee:	Susan McCourt <susan>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	malgorzata.tomczyk, Mike_Wilson, simon_kaegi, susan
Version:	0.2
Target Milestone:	0.2
Hardware:	PC
OS:	Linux
Whiteboard:

Description Andrew Niefer

2011-02-24 15:11:30 EST

In the navigator, with some project containing a directories nested a few levels deep, navigate down to some file, and click to open the editor on it.

Once in the editor, press the browser back button to return to the navigator.  This returns you to a collapsed navigator, it would be much more convenient if the navigator remained in the same expanded state we left it in.

Comment 1 Mike Wilson

2011-03-07 13:27:20 EST

Not sure what it would take to make this work, but I have to say the current behavior is frustrating. I hit it constantly.

Comment 2 Susan McCourt

2011-03-09 19:57:59 EST

I'll be doing something similar with selection caching in bug 339450, so I'm marking M7.  I assume we'll use some kind of session cookie.

Comment 3 Susan McCourt

2011-04-06 15:53:06 EDT

This and bug 339450 both involve caching of UI state so that page transitions/history return you to a more usable state.

I'm wondering what we should use to store this info.  It seems like a good idea to use a common API (preferences?) and then we could retarget the back end storage as needed.

- we use cookies elsewhere, as does dojo, for things like splitter location, etc.  This can be a pain for testing and remote reproduction of bugs.
- I was thinking of simply using preferences and taking advantage of the session caching that we do.  This way we retain the info per user.  Do we need an expiration on this kind of state?  (Would you expect your navigator at any given location to always open with your last expanded or selection state?)

Any other ideas?

Comment 4 Susan McCourt

2011-04-06 18:03:45 EDT

Fixed in HEAD.
I used user preferences to store the UI state.  The preference node is defined as "Navigator/rootlocationid/uiState"
where rootlocationid is basically the root location with special characters stripped out.

This way we can store the UI state at any level in the navigator.

Gosia - the first segment of the pref path is defined by the client.  So if you want caching of UI state in the Git UI, you need to specify the property "cachePrefix" in the options that you give to your explorer renderer.  For example, the navigator does:  

this.renderer = new eclipse.FileRenderer({checkbox: true, cachePrefix: "Navigator" }, this);

Comment 5 Simon Kaegi

2011-04-06 21:30:14 EDT

User settings are a store per site backed by localStorage. I think perhaps sessionStorage would be a better choice here - e.g. state per tab (per site)

Comment 6 Susan McCourt

2011-04-07 10:21:25 EDT

(In reply to comment #5)
> User settings are a store per site backed by localStorage. I think perhaps
> sessionStorage would be a better choice here - e.g. state per tab (per site)

This makes sense to me.  I switched to sessionStorage for nav UI state.   It's all in one place so easy enough to change.  We may find over time that there are some ui state settings that are important enough to preserve in the user space, but I don't think expansions and selections fall in that category.