Community
Participate
Working Groups
0.2M6 I have a scenario similar to this: 1. Client A does preferencesService.getPreferences("/window").then( ... ) 2. Before A's promise is resolved, client B does preferenceService.getPreferences("/window/foo").then( ... ) 3. Time passes 4. A's then() handler fires with the expected result: the /window node 5. B's then() handler fires with the wrong result: /window instead of /window/foo This seems to be due to all Preferences objects sharing the same UserPreferencesProvider, which uses only 1 promise for all outstanding xhr calls. B gets the same promise as A, so it ends up with A's preference node.
I'm using preferences now to remember expanded state and selection state in the navigator. I'm seeing some bizarre timing-related bugs that I believe are related to this problem.
Sorry Susan. I'll bump the priority and take a look tomorrow.
(In reply to comment #2) > Sorry Susan. > I'll bump the priority and take a look tomorrow. I switched to sessionStorage as you suggested for UI state, so this is less an issue for me. (But I think it'd be cool to look at it because it sounds like it could introduce some very subtle bugs.)
Fixed in HEAD. John Reviewed.
