Community
Participate
Working Groups
0.3 M2 - Perform a global search - Expand the tree, and click on a search result - Go "Back" in the browser to the search results page -> The tree expansion state was lost. This is understandable because expansion state is not part of the resource representation, but as an end user it makes browsing through search results impractical.
We do retain this state for certain pages (like navigator), we probably need to make sure this code is in a common place. Also there are timing problems in the navigator ( bug 344737 ) with nested expansions (which is common in search results).
(In reply to comment #1) > We do retain this state for certain pages (like navigator), we probably need to > make sure this code is in a common place. Also there are timing problems in > the navigator ( bug 344737 ) with nested expansions (which is common in search > results). I noticed that navigator can only cache one level expansion. It makes sense for to have that pieces of code in a common place. I am quite depending on bug 344737 now.
I went through all the comments in bug 344737 again. I think the use case in search result may be a little different: In file navigator, you may want to cache completely all the expanded folders, while in search result page, doing that is not really needed. There are two reasons: 1. Expanding all previous nodes is expensive, as we may have to do in-file-search many times. 2. What user really wants is to come back to the previously selected match and go next/previous. So I think in search result page I will just cache the current file + current match. After coming back from browser, we will only need one in-file-search and all other expansions are not important at the moment. I am removing the dependence on bug 344737. Any comments?
(In reply to comment #3) > I went through all the comments in bug 344737 again. > I think the use case in search result may be a little different: > In file navigator, you may want to cache completely all the expanded folders, > while in search result page, doing that is not really needed. > There are two reasons: > 1. Expanding all previous nodes is expensive, as we may have to do > in-file-search many times. > 2. What user really wants is to come back to the previously selected match and > go next/previous. I'm not sure you know what the user really wants to do here. If they went to the trouble to expand a number of different results and then click on one, and then press "back" to see the list they had made, it will be gone. Bug given we have bug 344737 anyway, and not many complaints, this is likely good enough for 0.3.
fixed with 90d38a7b88b48fe6fb05f032de07c5446c263ee9. I am caching current file + current match and the flag of tree View/flat view. So when browser is back we just expand the current file and highlight the current match , with cached view flag. I am using window.sessionStorage to cache the above status. The status is based on search string.
