Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 313846

Summary:

Dialog popup from a parent shell is covers by another shell which is popup from the parent shell

Product:

[Eclipse Project] Platform

Reporter:

zhaozn

Component:

SWT

Assignee:

Scott Kovatch <skovatch>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

daniel_megert, markus.kell.r, mukund, raji, Silenio_Quarti

Version:

3.5.2

Flags:

Silenio_Quarti: review+

Target Milestone:

3.7 M1

Hardware:

Macintosh

OS:

Mac OS X - Carbon (unsup.)

Whiteboard:

Attachments:

Description	Flags
Sample code to reproduce dialog cover issue	none
Fix	none

Description zhaozn

2010-05-20 23:53:28 EDT

Build Identifier: SWT 3.5.2

On Mac, Dialog popup from a parent shell is covers by another shell which is popup from the parent shell

Reproducible: Always

Steps to Reproduce:
1. Create Shell A.On Shell A, there are two buttons, one (named "open Shell B") 1. Create Shell A.On Shell A, there are two buttons, one (named "open Shell B") can open a child Shell B, one (named "open dialog C") can open child dialog C.
2. Click "Open Shell B" to open Shell B, click "Open dialog C" to open dialog C
3. Now dialog C is foremost, drag dialog C to Shell B, now dialog C can covers Shell B - dialog C is on Shell B. Click Shell B to make it to the foremost, drag dialog C to Shell B, now Shell B is still on the top of dialog C - Shell B covers dialog C. Click Shell A to bring Shell A to foremost, drag dialog C to Shell B, dialog C can be on the top of Shell B this time.

Comment 1 zhaozn

2010-05-21 00:07:14 EDT

Created attachment 169453 [details]
Sample code to reproduce dialog cover issue

Comment 2 Raji Akella

2010-06-02 18:17:27 EDT

Problem is being reported by Lotus Sametime team.

Comment 3 Silenio Quarti

2010-06-10 10:59:15 EDT

Scott, please investigate this one.

Comment 4 Scott Kovatch

2010-06-10 12:17:19 EDT

Carbon or Cocoa? I assume Carbon since you set the platform but I want to be sure.

Comment 5 Raji Akella

2010-06-10 12:19:20 EDT

Carbon.

Comment 6 Scott Kovatch

2010-06-11 13:57:22 EDT

I think we're going to have to rethink the implementation of parent/child windows. Window groups can't be configured to give the right behavior. Shells should be able to layer independently but window groups create a new layer for all windows in the group. Same is true on Cocoa -- addChildWindow is not what you want to use.

Comment 7 Scott Kovatch

2010-06-11 13:57:56 EDT

The AWT had a similar problem, and I seem to recall we had to implement our own management of owned windows.

Comment 8 Scott Kovatch

2010-06-14 14:08:49 EDT

This may not be as big a change as I thought. Setting kWindowGroupAttrSelectAsLayer when creating the window group makes for better behavior; clicking on a dialog brings all of the windows in the group to the foreground so we don't have an active window behind an inactive window. Now I want to see what Windows does.

Comment 9 Scott Kovatch

2010-06-14 14:50:07 EDT

Created attachment 171860 [details]
Fix

This change sets kWindowGroupAttrSelectAsLayer when creating the window group. The behavior is now identical to Windows 3.6rc4 -- clicking on a child dialog activates it and brings its parent window to the front too, but the children always stays above the parent.

Comment 10 Scott Kovatch

2010-06-14 14:51:20 EDT

Silenio, please have a look. Then I have to figure out where it should be checked in. We will want this change for 3.6.1 as well.

Comment 11 Silenio Quarti

2010-06-14 16:12:33 EDT

The fix looks good to me.

Comment 12 Scott Kovatch

2010-07-14 19:04:33 EDT

Fixed in HEAD > 20100714.

Comment 13 Scott Kovatch

2010-07-14 19:04:43 EDT

Comment 14 Scott Kovatch

2010-07-15 12:38:39 EDT

Also fixed in 3.6 maintenance branch > 20100715.