Community
Participate
Working Groups
Favorites was relying on a setTimeout in Preferences to delay the init call in PreferencesService and give it a chance to add an event listener before the init call dispatched the favorites changed event. Favorites should instead be both getting all the favorites and adding itself as a listener.
Fixed in HEAD. Susan reviewed.
+1. If this were an eclipse RC1 I would say it's unnecessary but we are being much wilder than this. This is the kind of bug that gets noticed and may never get fixed in the course of release end game and is too boring a bug to fix when adding new stuff at the beginning of a release. So I say fix it while we are here. FWIW, originally when the services managed their own listeners (pre service registry), Boris and I talked about the old eclipse pattern where you have to: - get something - add a listener for it and thought it might be cool to have the listener always fire the event when it gets a new listener. Sort of like dependency injection. We were trying to avoid duplicating the "get and listen" pattern all over the place. When services moved to the service registry, I can remember wondering why this still worked. Simon told me he had to add a hack to keep from breaking favorites. So I think this proves that the "free get when you add a listener" is not a good idea and just causes confusion.
