JDK-8088856 : Umbrella : issues related to dynamic skin replacement
  • Type: Bug
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: 8
  • Priority: P4
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2013-10-13
  • Updated: 2022-12-13
  • Resolved: 2022-12-13
Related Reports
Blocks :  
JDK-8087680 - DatePicker doesn't give to instantiate skin object for existing control
Blocks :  
JDK-8090208 - ScrollBar is badly rendered, when skin is dynamicly replaced.
Blocks :  
JDK-8087803 - TitledPane rendering is broken, when skin is replaced.
Blocks :  
JDK-8087840 - ToolBar looses items alignment, when skin is replaced.
Blocks :  
JDK-8087865 - Labeled controls fail with skin replacement: text is lost
Blocks :  
JDK-8087968 - ComboBox fails with skin replacement : additional arrow is added
Blocks :  
JDK-8088300 - MenuBar gets twice rendered menus when skin is replaced
Blocks :  
JDK-8088490 - Pagination control disappears, when skin is replaced
Blocks :  
JDK-8088568 - TextField get artifacts, when skin is replaced.
Blocks :  
JDK-8088716 - Slider disappears, when its skin class is replaced
Blocks :  
JDK-8089068 - Accordion disappears, when skin is replaced
Blocks :  
JDK-8089422 - ScrollPane is broken, when its skin is dynamicly replaced.
Blocks :  
JDK-8089737 - SplitPane loses content, when skin is replaced
Blocks :  
JDK-8089946 - TabPane loses content rendering, when skin is replaced
Blocks :  
JDK-8087746 - ProgressBar disappears, when its skin class is dynamicly replaced
Relates :  
JDK-8241364 - ☂ Cleanup skin implementations to allow switching
Description
Run the attached appliction, select any control, click button to replace the skin.
Comments
duplicate of JDK-8241364
13-12-2022
This will be addressed in openjfx20, as a part of JDK-8241364
09-12-2022
The basic problem is that when skins are disposed, that they are not removing all children and listeners that were added to the control. This means that the skin is not truly disposed, and we run into visual and runtime glitches when properties change that the old skin observed. There are really two options to explore here: 1) Just fix up the skins so that they dispose properly. 2) Add some API (even if it is internal to start with) that acts as a conduit for all children modifications / listener modifications. This conduit can then record the totality of the changes, and either automatically dispose of these modifications, or throw an exception when dispose is called and not all modifications are cleaned up. My preference is approach two, but it won't be a small undertaking, so I think for now it can be pushed out of JDK 9.
01-05-2016
Reminder for when I look into this: the set method inside the Control skin property has the following code which prevents the new skin from being set: if (v == null ? oldValue == null : oldValue != null && v.getClass().equals(oldValue.getClass())) return;
13-10-2013