Behavior reproducible in r448.
Steps to reproduce:
1) Create object (object0)
2) Maximize object
3) Create object (object1, should be maximized)
4) Add a D&D action to foreground object (such as Move in Direction, should get added to object1)
*) Bug: Object0 becomes new foreground frame, and Object1 becomes background frame.
Note, the bug is only a visual bug, and does not cause erroneous behavior to the backend. The D&D action belongs to Object1 still, and Object0 will remain unchanged.
Workaround: None, aside from ignoring or not using maximized windows.
useradd
more /root/Bugs/Maximized resources lose depth ordering.thread
For reference, the action frame is triggered (opened) in org.lateralgm.components.ActionList.openActionFrame().
Forcing a parent.toFront() prior to the ActionFrame's setVisible is ineffective, however forcing it after achieves the desired effect. Forcing it after the ActionFrame's toFront also achieves the desired effect without hiding the ActionFrame - expected behavior since the ActionFrame is a zchild.
This suggests that the setVisible method in the ActionFrame may have something to do with it.
New temporary Workaround: Force parent.toFront after the ActionFrame is made visible.
Around line 137:
Forcing a parent.toFront() prior to the ActionFrame's setVisible is ineffective, however forcing it after achieves the desired effect. Forcing it after the ActionFrame's toFront also achieves the desired effect without hiding the ActionFrame - expected behavior since the ActionFrame is a zchild.
This suggests that the setVisible method in the ActionFrame may have something to do with it.
New temporary Workaround: Force parent.toFront after the ActionFrame is made visible.
Around line 137:
Code
af.setVisible(true); if (parent != null) parent.toFront(); af.toFront();
Following this clue, I looked into af.setVisible, which is MDIFrame.setVisible. Here we see some very suspicious code which is most likely the culprit. We see an if statement: "if (pane.isMaximum() && isMaximizable())" which, in our case, is true && false, so we follow the else statement: "pane.bringMaximumToTop();" where pane is the MDIPane (the desktop area). The name of this method suggests that it finds the maximum frame(s) and brings it (them) to the top. The code behind this method supports this, by doing an iteration. Off the top of my head I don't know why this is useful, and especially not why it might be useful here.
I suspect the iteration is done in some wonky order (perhaps by depth), causing our frame to get lost to another frame being brought to front.
I now have the lead I'm looking for. Now to figure out how to fix it without breaking this code. The code was written and maintained by clam, so perhaps he might know something. Maybe I can go yell at him for not documenting this code since the logic isn't obvious :-p
I suspect the iteration is done in some wonky order (perhaps by depth), causing our frame to get lost to another frame being brought to front.
I now have the lead I'm looking for. Now to figure out how to fix it without breaking this code. The code was written and maintained by clam, so perhaps he might know something. Maybe I can go yell at him for not documenting this code since the logic isn't obvious :-p
r451 implements the temporary workaround. That just hides the bug, however, so this topic stays open until the bug is actually resolved.