Bugzilla – Full Text Bug Listing
| Summary: | Consumer of selection is called twice in ESelectionService | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Thorsten Lichtenwalter <lichtes> |
| Component: | UI | Assignee: | Oleg Besedin <ob1.eclipse> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | bsd, emoffatt, kai.toedter, nobody, ob1.eclipse, pwebster |
| Version: | 4.2 | ||
| Target Milestone: | 4.2 M7 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
I'll have a look at this. This turns out to be an interesting situation. The call stack looks like this: Part context#set(org.eclipse.ui.output.selection) -> SelectionAggregator -> -> Window context #set(org.eclipse.ui.selection) (1) -> -> -> E4Applcation.RAT (active window to app) -> -> -> -> Workbench context#set(org.eclipse.ui.selection) !-> -> -> -> DetailsView.setSelection(Contact) line: 204 (2) -> -> -> DetailsView.setSelection(Contact) line: 204 The selection value is modified at the window level and causes selection update to fire (1); then the previously scheduled update from the window context fires (2). We have a RaT that updates value in the parent context and that causes first call. Of course from the Part's viewpoint this makes no sense as both values (the one set directly and the one set by RaT) are the same. I added an extra check for context children invalidation. Git reference: http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=1cb899b8ee8e083da5db26f48e404506133dce4b Verified in I20120503-1800. |
Build Identifier: I20120315-1300 While using the ESelectionService by Dependency Injection in the Eclipse 4.2.0 i discovered the following bug: the part which is consuming the selection is called twice. Snippet of consuming part: @Inject public void setSelection( @Optional @Named(IServiceConstants.ACTIVE_SELECTION) IContact contact) { … Reproducible: Always