#20213 closed defect (fixed)
Command stack: Edits in relation editor are listed in wrong stack and lead to exception.
Reported by: | skyper | Owned by: | GerdP |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | Core | Version: | latest |
Keywords: | template_report command stack relation editor | Cc: |
Description
It seems #17196 is not completely fixed, yet.
What steps will reproduce the problem?
- Have to data layers one with at least one relation
- Open the relation in relation manager
- Switch active layer to the one without the relation
- Make some changes in relation editor and save + close
- Look at comman stack and notice a relation with negative id
- Undo last change
- Switch active layers back and for
- Redo change
What is the expected result?
- The command stack for the layer where the relation was opened from needs to list the changes in the relation editor
- No exception after redo
- No new "clone" relation but proper changes of the existing relation
What happens instead?
- The wrong command stack is used.
- ArrayIndexOutOfBoundsException
- New "clone" relation instead of changing the existing relation
Please provide any additional information below. Attach a screenshot if possible.
The relation editor always needs to be tied to one data set and only this layer should be changed and only its command stack be used.
Do not know what to do when layers are merged, but guess the datasets shoud be merged. We need to catch this situation as otherwise multiple relation editors could be open for the same relation in the same dataset or some will loose their dataset.
Relative:URL: ^/trunk Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last:Changed Date: 2020-12-07 15:40:50 +0100 (Mon, 07 Dec 2020) Revision:17396 Build-Date:2020-12-08 02:30:55 URL:https://josm.openstreetmap.de/svn/trunk Identification: JOSM/1.5 (17396 en) Linux Debian GNU/Linux 10 (buster) Java version: 11.0.9.1+1-post-Debian-1deb10u2, Debian, OpenJDK 64-Bit Server VM Dataset consistency test: No problems found Last errors/warnings: - 07910.694 E: Handled by bug report queue: java.lang.ArrayIndexOutOfBoundsException: 0 >= 0 === REPORTED CRASH DATA === BugReportExceptionHandler#handleException: No data collected. Warning issued by: BugReportExceptionHandler#handleException === STACK TRACE === Thread: AWT-EventQueue-0 (18) of main java.lang.ArrayIndexOutOfBoundsException: 0 >= 0 at java.base/java.util.Vector.elementAt(Vector.java:497) at java.desktop/javax.swing.tree.DefaultMutableTreeNode.getChildAt(DefaultMutableTreeNode.java:246) at org.openstreetmap.josm.gui.dialogs.CommandStackDialog.swapNode(CommandStackDialog.java:406) at org.openstreetmap.josm.gui.dialogs.CommandStackDialog.commandRedone(CommandStackDialog.java:400) at org.openstreetmap.josm.data.UndoRedoHandler$CommandRedoneEvent.fire(UndoRedoHandler.java:244) at java.base/java.lang.Iterable.forEach(Iterable.java:75) at org.openstreetmap.josm.data.UndoRedoHandler.fireEvent(UndoRedoHandler.java:454) at org.openstreetmap.josm.data.UndoRedoHandler.redo(UndoRedoHandler.java:430) at org.openstreetmap.josm.data.UndoRedoHandler.redo(UndoRedoHandler.java:416) at org.openstreetmap.josm.actions.RedoAction.actionPerformed(RedoAction.java:39) at java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1967) at java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2308) at java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:405) at java.desktop/javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:262) at java.desktop/javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:279) at java.desktop/java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:297) at java.desktop/java.awt.Component.processMouseEvent(Component.java:6635) at java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3342) at java.desktop/java.awt.Component.processEvent(Component.java:6400) at java.desktop/java.awt.Container.processEvent(Container.java:2263) at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5011) at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2321) at java.desktop/java.awt.Component.dispatchEvent(Component.java:4843) at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4918) at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4547) at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4488) at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2307) at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2772) at java.desktop/java.awt.Component.dispatchEvent(Component.java:4843) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95) at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745) at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
Attachments (0)
Change History (8)
comment:1 Changed 6 weeks ago by
Priority: | normal → major |
---|
comment:2 Changed 6 weeks ago by
Owner: | changed from team to GerdP |
---|---|
Status: | new → assigned |
comment:3 Changed 6 weeks ago by
comment:4 Changed 6 weeks ago by
I do not think hiding is a good idea, as right now I can select object if they are present in the active layer, which is nice. What does happen if you delete an inactive layer and the relation editor is still open with unsaved changes? What does happen when layers are merged?
Each relation editor needs to be directly tied to one dataset/layer and only objects from this layer are allowed to be added. If the relation is saved from relation editor these changes need to be made in this layer and its command stack.
comment:5 Changed 6 weeks ago by
Argh. Merging layers while relation editor is open is surely a good source for problems. I'll see if I find a simple solution. If not, I'll revert the changes for #17196.
comment:6 Changed 6 weeks ago by
Deleting and merging layers with an open relation manager is not a new problem. We need at least a warning and the relation editor should be closed or tied to the new layer.
One step in this direction might be #10032.
comment:8 Changed 3 weeks ago by
Do I set a milestone for tickets which don't concern tested versions?
I cannot reproduce the crash but I see the command in the wrong stack. Would it be an option to hide the relation editor windows which don't belong the active layer?