| Summary: | [PerspectiveBar] [Compatibility] New windows open are pushed behind originating window | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Brian de Alwis <bsd> | ||||
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> | ||||
| Status: | CLOSED FIXED | QA Contact: | Eric Moffatt <emoffatt> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | ||||||
| Version: | 4.1 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | Macintosh | ||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Brian de Alwis
Created attachment 203100 [details] Patch to StackRenderer's ActivationJob In digging into this, I should note that you need to open the perspective through Window > Open Perspective and not the Perspective Switcher. (The Perspective Switcher ignores the IPreferenceConstants.OPEN_PERSP_MODE = OPM_NEW_WINDOW setting; I have filed this separately as bug 357295.) What happens is that after opening the window, a PartStack in the original window (seemingly the top-level PartStack in the perspective) is activated for some reason, causing an activate-part event and triggering a setFocus(). Tracing execution through StackRenderer's ActivationJob, shouldActivate() returns true for this stack as the application's active child == application.getSelectionElement(). I think it should also check that the stackToActivate is a stack in the current window too. The patch attached here does this. (I'm experiencing deja vu — I think I reported a similar problem a year ago…) Verified in 4.2M3 |