Community
Participate
Working Groups
Every now and then (!?!) I notice that my favorites go missing. And then they come back. It happened yesterday after a session of being logged into Anton's Orion to look at his site and code. And it happened around the time that I was reading the N&N page that John published from an Orion site. So I'm wondering if the localStorage for preferences is keyed by something that doesn't include the user name. Could using Anton's install have wiped out my preferences, and then they were empty until I did something to fetch the server-stored preferences back?
I think my theory about running someone else's Orion is bogus. Perhaps this happens more frequently than I think. It happened this morning (does it happen on every new build?)
FWIW I have favorites I created on orion.eclipse.org I created months ago that I have never lost. I wonder if something you're doing with your "inner" site is interfering?
I never lose them per se, I can get them right back by reloading the page. It seems like when I log in after a new build has been deployed, my favorites are usually empty and then a reload gets them back. But there definitely could be some inner site stuff at play.
I think this is just a "first time you use the server." It happens every time a build is deployed. Not only does the favorites pane not fill in, but if you use "Ctrl+Shift+F" there are no favorites in that list either. Could be a race condition with the favorites cache, or something like that...I will revisit the flow.
I think what's going on here is that the favorites service doesn't try to use an authenticated service, so it just loads "no favorites." Then the nav tries to use the file service, and you authenticate. Now the nav loads, but the favorites is showing the stale data. Simon, is there anything in the new login sequence cycle that will help with this?
Simon says he will look at this one.
The login cycle should prevent this from occuring. I suspect the problem is we're caching without responding to logout events correctly.
Moving to 1.0 -- changing title to reflect a need to re-examine how we cache in localstorage and manage the life of things we cache
The changes here are incredibly important but too risky for 1.0. This means async prefs and ad-hoc inter-tab communication via local storage for 1.0. I'm going to move to 2.0 M1.
This open bug report had a target milestone in the past. The target milestone has been removed. Please target for a date in the future or leave the target blank if it is not known.
It seems to me that the local storage caching/lifecycle isn't a problem in daily usage of Orion. This bug is a few years old. Closing.
