Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 357292 - [PerspectiveBar] [Compatibility] New windows open are pushed behind originating window
Summary: [PerspectiveBar] [Compatibility] New windows open are pushed behind originati...
Status: CLOSED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.1   Edit
Hardware: Macintosh Mac OS X - Carbon (unsup.)
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact: Eric Moffatt CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-09 18:28 EDT by Brian de Alwis CLA
Modified: 2011-11-01 19:29 EDT (History)
0 users

See Also:


Attachments
Patch to StackRenderer's ActivationJob (764 bytes, patch)
2011-09-09 21:19 EDT, Brian de Alwis CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Brian de Alwis CLA 2011-09-09 18:28:54 EDT
I use multiple windows in development.  I set "Preferences > General > Perspectives > Open a new perspective > In a new window".  When I open a new perspective, the new window is opened, the perspective populates, and then the new window is pushed into the background.  The new window should remain in the foreground and receive focus.
Comment 1 Brian de Alwis CLA 2011-09-09 21:19:08 EDT
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…)
Comment 2 Brian de Alwis CLA 2011-11-01 19:29:17 EDT
Verified in 4.2M3