JDK-8039945 : JDesktopPane's remove(Component) should check componentOrderCheckingEnabled
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 7u45
  • Priority: P3
  • Status: Closed
  • Resolution: Incomplete
  • OS: windows_7
  • Submitted: 2013-12-10
  • Updated: 2017-06-19
  • Resolved: 2017-06-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbd_majorResolved
Related Reports
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) Client VM (build 24.0-b56, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :
With update 40, the following code was added to JDesktopPane:

    @Override
    public void remove(Component comp) {
        super.remove(comp);
        updateFramesCache();
    }

I think I understand why it was added, but I believe it is not correct.  It should not call updateFramesCache if the property componentOrderCheckingEnabled is set to false.  This is how it works the JDesktopPanes other add and remove methods:

remove(int)
removeAll()
addImpl(...)

This is causing an issue in our MDI application when the user hits ctrl-F6 to go to the next frame.  We subclass the DefaultDesktopManager and in our activeFrame code, we have code that eventually calls JDesktopPane's remove(Component method.  This code reorders the "framesCache" which means Ctrl-F6 does not visit all frames.



REGRESSION.  Last worked in version 7u25

ADDITIONAL REGRESSION INFORMATION:
The problem was introduced in update 40 and is still there in update 45.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Using highly customized application so difficult to reproduce in standalone code.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Do not call updateFramesCache() unless the property componentOrderCheckingEnabled  is false.
ACTUAL -
Calling updateFramesCache() even when the property componentOrderCheckingEnabled  is false.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
I would love to give you a small sample application demonstrating this, but we have special handling in our MDI application so it is difficult to do.  If you really need it, then i can spend more time trying to create one.  My first attempts were not successful.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Override the JDesktopPane's remove(Component) method and copy the Containers code into it.  This is very ugly.
Comments
I believe we need to check componentOrderChanged before calling updateFramesCache() but in absense of reproducible testcase, we will not be able to make this change and test.
19-06-2017

- this is an issue reported against 7(7u), - there are now affected version 9 filed for this issue - 7u issues are transferred to Sustaining Nevertheless if someone have a report against 9 - please reopen and add affectedVersion 9 or 7u specific escalations might be reopen to Sustaining
10-08-2014

- this is an issue reported against 7(7u), - there are now affected version 9 filed for this issue - 7u issues are transferred to Sustaining Nevertheless if someone have a report against 9 - please reopen and add affectedVersion 9 or 7u specific escalations might be reopen to Sustaining
10-08-2014

not a regression in 8 or 9
16-05-2014

is it affected 8 or 9 ?
10-04-2014