8296621: Stage steals focus on scene change

[tsayao]

Simple fix to not requestFocus() on scene change.

The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author)

Issue

• JDK-8296621: Stage steals focus on scene change

Reviewers

• Kevin Rushforth (@kevinrushforth - Reviewer)
• Michael Strauß (@mstr2 - Committer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jfx pull/940/head:pull/940
$ git checkout pull/940

Update a local copy of the PR:
$ git checkout pull/940
$ git pull https://git.openjdk.org/jfx pull/940/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 940

View PR using the GUI difftool:
$ git pr show -t 940

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/940.diff

[bridgekeeper]

👋 Welcome back tsayao! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[mlbridge]

Webrevs

• 06: Full - Incremental (35f657a7)
• 05: Full - Incremental (bf0177b9)
• 04: Full - Incremental (8ce83fde)
• 03: Full - Incremental (39d74209)
• 02: Full - Incremental (f3c7097b)
• 01: Full - Incremental (113e472a)
• 00: Full (c3252bd0)

[kevinrushforth]

I agree that changing from one scene to another should not cause a new request focus call. My only concern is to ensure that this will not cause any regressions for the initial setting of a scene. A safer change might be to qualify the existing call to requestFocus with a check of the previous scene, and only call it if oldScene == null.

/reviewers 2

[mstr2]

After the fix, the behavior looks similar on all platform, but this way the user does not get any notification of the Scene change in Application's content. i.e. the behavior change on Windows(icon not flashing) and Mac(not bringing Stage to foreground) seem little undesirable change to me.

Should we consider to atleast bring the Stage to foreground without stealing focus ? or any alternatives ?

A Scene is an implementation detail of a JavaFX application, and not something that users of an application will find meaningful. Since we don't attempt to change the window stacking order when the scene graph is changed, we also shouldn't attempt to do so when a Scene is changed.

In any case, Windows doesn't allow applications to force a window to the foreground, so that wouldn't work anyway. If a non-foreground process tries to set the foreground window, the call to SetForegroundWindow will fail, and the taskbar icon will flash instead.

[kevinrushforth]

I'll finish my testing soon. As long as the behavior for the initial display of the Stage is the same on all platforms before/after this fix, I think it is fine. In particular, the "after" behavior for switching Scenes that Ambarish documented above is what I would expect after this bug fix is integrated.

A Scene is an implementation detail of a JavaFX application, and not something that users of an application will find meaningful. Since we don't attempt to change the window stacking order when the scene graph is changed, we also shouldn't attempt to do so when a Scene is changed.

Exactly what I was going to say.

[arapte]

Suggesting minor changes in the test.

[openjdk]

⚠️ @tsayao This pull request contains merges that bring in commits not present in the target repository. Since this is not a "merge style" pull request, these changes will be squashed when this pull request in integrated. If this is your intention, then please ignore this message. If you want to preserve the commit structure, you must change the title of this pull request to Merge <project>:<branch> where <project> is the name of another project in the OpenJDK organization (for example Merge jdk:master).

[kevinrushforth]

I still need to do a little more testing, but so far, the fix looks good to me.

As for the test, I left an inline comment answering your question. More importantly, though, the test doesn't catch the bug. It passes both with and without your fix on all three platforms.

[kevinrushforth]

One other thing to note about the test, and also about the test case from the bug report on which it was based: The fact that the test sets the scene in rapid succession to two different values (at time = N, and immediately thereafter at time = 0) has uncovered a bug in JavaFX. I see an intermittent NPE in Window::adjustSize with a scene that is transiently null. I'll submit a new bug with a modified version of the test program attached to this bug.

[tsayao]

I still need to do a little more testing, but so far, the fix looks good to me.

As for the test, I left an inline comment answering your question. More importantly, though, the test doesn't catch the bug. It passes both with and without your fix on all three platforms.

That's odd, It does consistently fail/works for me when I add/remove requestFocus().

[kevinrushforth]

It might be timing problem. I ran it a couple more times without the fix and it failed once (so it failed 2 out of 3 times). I'll test it again now that you've updated the test.

[kevinrushforth]

Yes, it is a timing problem, most likely related to the performance of my Ubuntu 20.04 VM. I left comments inline with two suggested changes (I think only the first is necessary, but setting iconify before the stage is shown may make the test more robust). With those changes, it fails reliably without your fix and passes reliably with your fix.

[kevinrushforth]

Looks good.

[openjdk]

@tsayao This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8296621: Stage steals focus on scene change

Reviewed-by: kcr, mstrauss

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 5 new commits pushed to the master branch:

• f96b350: 8296854: NULL check of CTFontCopyAvailableTables return value is required
• 6f36e70: 8295175: SplitPaneSkin: memory leak when changing skin
• bb13920: 8295531: ComboBoxBaseSkin: memory leak when changing skin
• f333662: 8297413: Remove easy warnings in javafx.graphics
• 7b3c88b: 8295324: JavaFX: Blank pages when printing

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[tsayao]

/integrate

[openjdk]

Going to push as commit 5b0d3b5.
Since your change was applied there have been 5 commits pushed to the master branch:

• f96b350: 8296854: NULL check of CTFontCopyAvailableTables return value is required
• 6f36e70: 8295175: SplitPaneSkin: memory leak when changing skin
• bb13920: 8295531: ComboBoxBaseSkin: memory leak when changing skin
• f333662: 8297413: Remove easy warnings in javafx.graphics
• 7b3c88b: 8295324: JavaFX: Blank pages when printing

Your commit was automatically rebased without conflicts.

[openjdk]

@tsayao Pushed as commit 5b0d3b5.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.