| Summary: | [Compatibility] selection change includes one call with old value | ||
|---|---|---|---|
| Product: | [Eclipse Project] e4 | Reporter: | Paul Webster <pwebster> |
| Component: | UI | Assignee: | Remy Suen <remy.suen> |
| Status: | RESOLVED INVALID | QA Contact: | Paul Webster <pwebster> |
| Severity: | normal | ||
| Priority: | P3 | CC: | gheorghe, remy.suen |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Paul Webster
I can't induce the same stack trace (presumably because of the changes that's been in this code) but I do get the same behaviour. The reason there are two selection events is because the first one is fired for when the control gets activated by the mouse click. At this point in time, the selection has not yet been changed to the new selection so an event is fired for the original selection. UI processing continues and then the mouse click is registered with the control in question and the new selection occurs which triggers the second selection event (with the "correct" new selection). With that in mind, this behaviour is correct and in line with what happens in 3.x. Resolving as INVALID. |