Bugzilla – Full Text Bug Listing
| Summary: | [client] Issue with concurrent calls to PreferencesService.getPreferences() | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Mark Macdonald <mamacdon> |
| Component: | Client | Assignee: | Simon Kaegi <simon_kaegi> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | simon_kaegi, susan |
| Version: | 0.2 | ||
| Target Milestone: | 0.2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
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. |
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.