Bugzilla – Full Text Bug Listing
| Summary: | Test failures in EPartServiceTest, ESelectionServiceTest | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] e4 | Reporter: | Remy Suen <remy.suen> | ||||||
| Component: | UI | Assignee: | Project Inbox <e4.ui-inbox> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | ob1.eclipse | ||||||
| Version: | 1.0 | ||||||||
| Target Milestone: | 1.0 M5 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
I've looked at one of the test failures - testEvent_PartActivated2() and it seems to be a problem with the expected test result. What seems to happen, is that partServiceB activates a part which gets propagated to the parent context: parentContext.set(IContextConstants.ACTIVE_CHILD, curContext); The partServiceA relies on the child of that context which has no active child set at this point, so the active part value gets propagated to the partServiceA. Are partServiceA and partServiceB supposed to produce different results when asked what is the active part? (Which can be turned into a more interesting question, why would we have multiple part services in the same model.) (In reply to comment #1) > The partServiceA relies on the child of that context which has no active child > set at this point, so the active part value gets propagated to the > partServiceA. The partServiceB is activating parts that it doesn't know about (partA and partB are both in windowA). Technically speaking, the activate request from partServiceB should be a no-op. > Are partServiceA and partServiceB supposed to produce different results when > asked what is the active part? Yes. The active part of windowA should not be the active part of windowB. Every workbench window has its own active part. (In reply to comment #2) > The partServiceB is activating parts that it doesn't know about (partA and > partB are both in windowA). Technically speaking, the activate request from > partServiceB should be a no-op. Correction! :/ Both parts are in windowB. Activating those parts should not cause part events in windowA because windowA does not know about those parts. Created attachment 163941 [details]
Tests patch to reproduce the problem
This test will reproduce the problem with pure context-related code.
It seems the RAT's invocation inadvertently causes window B to be injected. I would expect window B's part to always be computed from the context function (which should always be null because it has no active child context).
(In reply to comment #4) > It seems the RAT's invocation inadvertently causes window B to be injected. I > would expect window B's part to always be computed from the context function > (which should always be null because it has no active child context). If I set new instances of the same context function to both windows then the propagation doesn't seem to happen. So in that regard scoping will be correct. Created attachment 163956 [details]
Patch
While working on e4 every now and then I feel like Alice in Wonderland. This is the fix for my earlier fix.
Both patch and the test released to CVS Head. Remy, thank you for finding this and taking time to prepare the test case! |
EPartServiceTest -testEvent_PartActivated2 -testEvent_PartDeactivated2 -testSwitchWindows ESelectionServiceTest -testThreePartSelection If I rollback attachment 163896 [details], the problem goes away. It's quite possible the culprit is in the EPS/ESS implementations themselves. Will take a look.