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

Bug 18483

Summary:	IE6 causes conflict with SWT.APPLICATION_MODAL on Windows 98
Product:	[Eclipse Project] Platform	Reporter:	Tod Creasey <Tod_Creasey>
Component:	SWT	Assignee:	Steve Northover <snorthov>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3
Version:	2.0
Target Milestone:	---
Hardware:	PC
OS:	Windows 98
Whiteboard:
Bug Depends on:
Bug Blocks:	18399

Description Tod Creasey

2002-05-31 13:51:52 EDT

Build 20020531

When IE 6 is installed on Windows 98 it replaces the task bar with one of its 
own (according to Dave Thomson). When this occurs the focus behaviour of shells 
with modality set to SWT.APPLICATION_MODAL  changes.

STEPS
1) Start Windows 98 on a machine with IE 5 or earlier
2) Select a file
3) Hit delete - a prompter comes up
4) Select an non Eclipse window and drag it over the dialog
5) Select the Eclipse parent window in the tasks list - the dialog and window 
are given focus
6) Start Windows 98 on a machine with IE 62) Select a file
3) Hit delete - a prompter comes up
4) Select an non Eclipse window and drag it over the dialog
5) Select the Eclipse parent window in the tasks list - the dialog only is 
given focus and the window stays in the backgroud.

I don't have a good pure SWT example of this yet as I am still trying to find 
the condition that makes this happen.

Comment 1 Mike Wilson

2002-05-31 14:02:44 EDT

Is the dialog a child of the shell? If it isn't there's no reason for the shell to 
come to the front when the dialog does. 

In any case, this seems like a minor issue to me. Do you believe this 
needs to be addressed for R2.0?

Comment 2 Tod Creasey

2002-05-31 14:08:05 EDT

The dialog shell is the child of the window shell.

I do not believe this is a major issue for 2.0 as the user loses no 
information - i.e. the modal shell is the one they see so there are no mystery 
dialog preventing them working.

Comment 3 Mike Wilson

2002-05-31 14:14:34 EDT

Basically, I believe you are seeing something which would be true for 
every windows app: Installing the new IE changes the behavior. As long 
as this isn't causing anyone any real grief, I'm not even going to look at it 
until after R2.0.

Comment 4 Dave Thomson

2002-05-31 14:29:25 EDT

This is not an issue for 2.0.  However I believe it does expose a bug in our 
code.  Not ALL of our dialogs exhibit this behavior - in fact most of them work 
correctly.  Other applications also work correctly and are not affected by IE 6.

Only certain of our dialogs (such as the one in the test case) work 
incorrectly, so it could indicate a problem with the way the particular dialog 
is create or its relationship to the underlying shell.

Comment 5 Mike Wilson

2002-05-31 14:42:14 EDT

The reason I asked the question "Is the dialog a child of the parent?" is 
because I have had cases in the past where we tried to debug one of 
these but eventually proved that the dialog's parent was null (even though 
we were told by the UI team that it was not). If this is true, then the new "IE 
6" specific behavior is the correct behavior. This would certainly explain 
the fact that some dialogs exhibit the behavior and some do not.

Another possibility would be that the dialogs that work are the built in 
dialogs, and all "hand rolled" dialogs are broken, in which case the 
problem would definately be in our code.

In any case, as previously stated. This bug is LATER.

Comment 6 Nick Edgar

2002-05-31 16:30:52 EDT

Confirmed that we are setting the parent shell properly.
I saw the problem with the Navigator on my home machine (XP), but not at work 
(also XP).  Both have IE 6.

Comment 7 Veronika Irvine

2002-09-11 14:07:43 EDT

Moving from Later.

Comment 8 Steve Northover

2002-09-12 09:31:14 EDT

Tod, can you try this again with the "32770" changes?

Comment 9 Tod Creasey

2002-09-17 10:17:30 EDT

Works with the 32270 changes in build 20020911. Closing.