Bug 297510 - [Widgets] Calling Composite#setFocus() before shell is opened sets focus to nowhere
Summary: [Widgets] Calling Composite#setFocus() before shell is opened sets focus to n...
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.6   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 4.12 M1   Edit
Assignee: Rolf Theunissen CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 56124 (view as bug list)
Depends on:
Blocks: 545864
  Show dependency tree
 
Reported: 2009-12-10 12:18 EST by Markus Keller CLA
Modified: 2022-02-28 04:38 EST (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2009-12-10 12:18:31 EST
I20091209-1800

Run the snippet below. On WinXP, the focus is not in the text widget when the shell is opened. On GTK, it is.

Found through bug 297187 comment 9 (worked fine on GTK but failed on Windows).


package snip;

import org.eclipse.swt.*;
import org.eclipse.swt.layout.*;
import org.eclipse.swt.widgets.*;

public class Snip0 {
    public static void main(String[] args) {
        Display display= new Display();
        final Shell shell= new Shell(display);
        shell.setLayout(new FillLayout());

        Composite c= new Composite(shell, SWT.NONE);
        c.setLayout(new GridLayout());
        
        new Text(c, SWT.BORDER);
        
        c.setFocus();
        
        shell.pack();
        shell.open();

        while (!shell.isDisposed()) {
            if (!display.readAndDispatch())
                display.sleep();
        }
        display.dispose();
    }
}
Comment 1 Markus Keller CLA 2010-10-28 13:34:10 EDT
Still an issue in HEAD. The problem is that Control#forceFocus() does this:

	shell.setSavedFocus (this);
	if (!isEnabled () || !isVisible () || !isActive ()) return false;

The calls to isVisible() and isActive() always fail if the parent shell is not visible. And when Control#forceFocus() returns false, then the calling Composite#setFocus() thinks it was not successful and tries the next widget, etc., and finally, it runs into bug 170631 comment 7, because the composite was the last widget that called "shell.setSavedFocus (this)".
Comment 2 Felipe Heidrich CLA 2010-11-04 16:24:46 EDT
I add this line after shell.open()

System.out.println(display.getFocusControl());

is print out "Composite", as I expected.

What is the problem you are trying to fix ?
Comment 3 Markus Keller CLA 2010-11-05 10:09:39 EDT
> is print out "Composite", as I expected.

That's not correct. The created widget tree looks like this:
  Shell
  + Composite
    + Text

When I call setFocus() on the Composite, the focus should be put into the first child of the Composite that can take focus. To see what it should do, move "c.setFocus();" after "shell.open();" (or run the snippet on GTK).
Comment 4 Leo Ufimtsev CLA 2017-08-03 12:32:39 EDT
This is a one-off bulk update. (The last one in the triage migration).

Moving bugs from swt-triaged@eclipse to platform-swt-inbox@eclipse.org and adding "triaged" keyword as per new triage process:
https://wiki.eclipse.org/SWT/Devel/Triage

See Bug 518478 for details.

Tag for notification/mail filters:
@TriageBulkUpdate
Comment 5 Eclipse Genie CLA 2019-03-27 15:57:31 EDT
New Gerrit change created: https://git.eclipse.org/r/139638
Comment 7 Lars Vogel CLA 2019-04-02 03:52:02 EDT
Thanks, Rolf for solving this 10 years old issue.
Comment 9 Lars Vogel CLA 2019-04-03 05:48:00 EDT
Rolf, please have a look.
Comment 10 Rolf Theunissen CLA 2019-04-03 07:17:17 EDT
First quick look, given that not only the test cases I changed, but also test_getActiveShell() fails:
- I expect this is caused by the shell not being active yet, see also bug 506680.
- Therefore, I expect that in a re-run a different set of test-cases related to focus fails.
Comment 11 Andrey Loskutov CLA 2019-04-03 08:22:18 EDT
(In reply to Rolf Theunissen from comment #10)
> First quick look, given that not only the test cases I changed, but also
> test_getActiveShell() fails:
> - I expect this is caused by the shell not being active yet, see also bug
> 506680.
> - Therefore, I expect that in a re-run a different set of test-cases related
> to focus fails.

Please note, we had "few" active shell issues on Mac before, but we got around 40 *new* fails on Mac.
Comment 12 Rolf Theunissen CLA 2019-04-03 08:41:41 EDT
(In reply to Andrey Loskutov from comment #11)
> Please note, we had "few" active shell issues on Mac before, but we got
> around 40 *new* fails on Mac.

39 of the *new* fails can be traced back to the changes in this patch. The 40th fail gives me a clue that it is related to (delayed) activation of the opened shell, moreover, we had similar activation problems on GTK.
I try to look at it in more detail tonight. I think that I will add to wait for the shell to become active after shell.open() (and shell.forceActive()). However, without having Mac hardware it might be a bit tricky to get these test cases stable.
Comment 13 Andrey Loskutov CLA 2019-04-03 09:08:52 EDT
(In reply to Rolf Theunissen from comment #12)
> However, without having Mac hardware it might be a bit tricky to get these
> test cases stable.

I wonder how you verified the fix for https://git.eclipse.org/r/#/c/139638/7/bundles/org.eclipse.swt/Eclipse+SWT/cocoa/org/eclipse/swt/widgets/Decorations.java without a Mac?

The problem is: do we really know that it is a "test only" issue, or the Mac port is somehow affected in a bad way? In doubt, I would revert Mac code changes.
Comment 14 Rolf Theunissen CLA 2019-04-03 09:43:44 EDT
(In reply to Andrey Loskutov from comment #13)
> (In reply to Rolf Theunissen from comment #12)
> > However, without having Mac hardware it might be a bit tricky to get these
> > test cases stable.
> 
> I wonder how you verified the fix for
> https://git.eclipse.org/r/#/c/139638/7/bundles/org.eclipse.swt/Eclipse+SWT/
> cocoa/org/eclipse/swt/widgets/Decorations.java without a Mac?
> 
> The problem is: do we really know that it is a "test only" issue, or the Mac
> port is somehow affected in a bad way? In doubt, I would revert Mac code
> changes.

Thanks to Karsten Thoms, see Gerrit change
Comment 15 Eclipse Genie CLA 2019-04-03 15:08:15 EDT
New Gerrit change created: https://git.eclipse.org/r/139981
Comment 17 Lars Vogel CLA 2019-04-05 05:38:54 EDT
Lets keep this open to see if the test are fixed with Rolfs recent change.
Comment 18 Andrey Loskutov CLA 2019-04-06 03:20:44 EDT
(In reply to Lars Vogel from comment #17)
> Lets keep this open to see if the test are fixed with Rolfs recent change.

Unfortunately the number of failures on Mac increased with latest change. Now we have 66 fails (was 42, and initially was 3 before the changes).

https://download.eclipse.org/eclipse/downloads/drops4/I20190405-1800/testresults/html/org.eclipse.swt.tests_ep412I-unit-mac64-java8_macosx.cocoa.x86_64_8.0.html

If we agree that the fix was functionally OK and that we only observe test issues, we should either have someone with Mac to check what is wrong or disable tests on Mac. I believe we had a bug anyway, that Mac tests have issues with focus and/or active shell detection.
Comment 19 Eclipse Genie CLA 2019-04-07 13:29:32 EDT
New Gerrit change created: https://git.eclipse.org/r/140173
Comment 20 Rolf Theunissen CLA 2019-04-07 13:34:16 EDT
(In reply to Andrey Loskutov from comment #18)
> (In reply to Lars Vogel from comment #17)
> > Lets keep this open to see if the test are fixed with Rolfs recent change.
> 
> Unfortunately the number of failures on Mac increased with latest change.
> Now we have 66 fails (was 42, and initially was 3 before the changes).
> 
> https://download.eclipse.org/eclipse/downloads/drops4/I20190405-1800/
> testresults/html/org.eclipse.swt.tests_ep412I-unit-mac64-java8_macosx.cocoa.
> x86_64_8.0.html
> 
> If we agree that the fix was functionally OK and that we only observe test
> issues, we should either have someone with Mac to check what is wrong or
> disable tests on Mac. I believe we had a bug anyway, that Mac tests have
> issues with focus and/or active shell detection.

I have tested on Mac now too. My previous patch I accidentally tested on an older Mac OS version, which was indeed different in focus behavior. I tested the latest gerrit on the latest Mac version, and locally it passed.
Comment 22 Andrey Loskutov CLA 2019-04-08 01:08:49 EDT
(In reply to Eclipse Genie from comment #21)
> Gerrit change https://git.eclipse.org/r/140173 was merged to [master].
> Commit:
> http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/
> ?id=ec88489807a92d066267929e843ec0c8f8dbd1ab

Didn't work either :(

https://download.eclipse.org/eclipse/downloads/drops4/I20190407-1800/testresults/html/-unit-mac64-java8_macosx.cocoa.x86_64_8.0.html
Comment 23 Niraj Modi CLA 2019-04-08 05:39:08 EDT
(In reply to Eclipse Genie from comment #6)
> Gerrit change https://git.eclipse.org/r/139638 was merged to [master].
> Commit:
> http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/
> ?id=a352fe3d2cc4c9803306f45213aea789cf998600

Hi Rolf,
Please have a look on below two Windows JUnits tests as well, which are failing after your above commit:
test_setFocus_toChild_beforeOpen
test_setFocus_toChild_afterOpen

Sharing the JUnit test results:
https://download.eclipse.org/eclipse/downloads/drops4/I20190402-1800/testresults/html/org.eclipse.swt.tests_ep412I-unit-win32-java8_win32.win32.x86_64_8.0.html
Comment 24 Lakshmi P Shanmugam CLA 2019-04-08 06:13:54 EDT
There are 66 test failures in SWT on Mac. 2 of them are old failures related to activate and are tracked by Bug 536564. Those 2 tests fails only on the test machine.
1 tracked by Bug 546192.
Rest of them seem to be caused by the changes for this bug. Test_org_eclipse_swt_widgets_Text.test_setForegroundAfterBackground even fails locally on my Mac (10.14).

@Rolf, are the failures caused by the changes to the code or test? 
Since, we are in milestone week and this causes new test failures on both Windows and Mac, I think we should revert the changes to code/test and look at adding them for M2.
Comment 25 Lakshmi P Shanmugam CLA 2019-04-08 06:23:35 EDT
(In reply to Lakshmi Shanmugam from comment #24)

> Test_org_eclipse_swt_widgets_Text.test_setForegroundAfterBackground even
> fails locally on my Mac (10.14).
This is tracked by Bug 546192.
Comment 26 Rolf Theunissen CLA 2019-04-08 07:37:44 EDT
(In reply to Lakshmi Shanmugam from comment #24)
> There are 66 test failures in SWT on Mac. 2 of them are old failures related
> to activate and are tracked by Bug 536564. Those 2 tests fails only on the
> test machine.
> 1 tracked by Bug 546192.
> Rest of them seem to be caused by the changes for this bug.
> Test_org_eclipse_swt_widgets_Text.test_setForegroundAfterBackground even
> fails locally on my Mac (10.14).
> 
> @Rolf, are the failures caused by the changes to the code or test? 
> Since, we are in milestone week and this causes new test failures on both
> Windows and Mac, I think we should revert the changes to code/test and look
> at adding them for M2.

The failures are caused by the test code, somehow the shell is not activated after which the test case fails. The test succeeded when run locally from Eclipse.
I cannot reproduce how the test run on the test-server, so best they can be disabled for Mac.
The failing test for windows, only fail for the browser widget, the test need some tweaking (or disable). I will look into those.
Comment 27 Lakshmi P Shanmugam CLA 2019-04-08 08:04:40 EDT
(In reply to Rolf Theunissen from comment #26)
> (In reply to Lakshmi Shanmugam from comment #24)
> > There are 66 test failures in SWT on Mac. 2 of them are old failures related
> > to activate and are tracked by Bug 536564. Those 2 tests fails only on the
> > test machine.
> > 1 tracked by Bug 546192.
> > Rest of them seem to be caused by the changes for this bug.
> > Test_org_eclipse_swt_widgets_Text.test_setForegroundAfterBackground even
> > fails locally on my Mac (10.14).
> > 
> > @Rolf, are the failures caused by the changes to the code or test? 
> > Since, we are in milestone week and this causes new test failures on both
> > Windows and Mac, I think we should revert the changes to code/test and look
> > at adding them for M2.
> 
> The failures are caused by the test code, somehow the shell is not activated
> after which the test case fails. The test succeeded when run locally from
> Eclipse.
> I cannot reproduce how the test run on the test-server, so best they can be
> disabled for Mac.
Shell activation has some problem on the test machine since Mac 10.13. The 2 failing tests in Bug 536564 fail due to the same issue, but they were existing tests that started failing. Please disable the new tests on Mac.

> The failing test for windows, only fail for the browser widget, the test
> need some tweaking (or disable). I will look into those.
The browser tests are failing on both Mac and Windows. We should either fix them or remove them, it doesn't seem like a good idea to add tests that are failing from the beginning and disable them on Windows and Mac.
Comment 28 Eclipse Genie CLA 2019-04-08 15:17:37 EDT
New Gerrit change created: https://git.eclipse.org/r/140240
Comment 30 Lakshmi P Shanmugam CLA 2019-04-09 04:00:46 EDT
Thanks Rolf! No new test failures on Windows and Mac - https://download.eclipse.org/eclipse/downloads/drops4/I20190408-1800/testResults.php
Comment 31 Lars Vogel CLA 2019-04-09 04:37:56 EDT
(In reply to Lakshmi Shanmugam from comment #30)
> Thanks Rolf! No new test failures on Windows and Mac -
> https://download.eclipse.org/eclipse/downloads/drops4/I20190408-1800/
> testResults.php

Finally... I was afraid about a big revert. Thanks, Rolf for taking responsibility.
Comment 32 Niraj Modi CLA 2019-04-11 08:04:53 EDT
Verified the fix in Build id: I20190410-1800 on Win7 using snippet in comment 0
Comment 33 Lakshmi P Shanmugam CLA 2019-12-20 07:44:46 EST
The fix caused Bug 547495. The snippet in comment#0 also fails on Mac.
Comment 34 Rolf Theunissen CLA 2022-02-28 04:25:10 EST
*** Bug 56124 has been marked as a duplicate of this bug. ***