Undo/Redo not recovering steps in order or missing steps

I noticed that while having shapes selected and working with nodes or applying booleans, if I interact with the layers (i.e, turn visibility on/off, or lock/unlock) then return to the canvas and continue working with nodes, in some cases the undo does not recover the steps in order and/or leaves some steps out of the undo queue.

If the latter occurs there is no way to undo that step. When the issue occurs, going forward with redo and backward with undo also affects the interaction with the layers. I think the issue is related to the fact that the history may be including the interaction with the layers and not only the work inside the canvas, which is my expectation for the undo/redo.

For example, I had 5 circles, I changed mode from selection to direct selection, I was tweaking the position of some of the nodes of these circles. I needed to check other layers then turned on/off some of them, including the layer where I was working on; I returned to this layer to continue work, realised that I made a mistake so I tried undo a few times.

The result was that all the layers went first hidden, so I tapped redo hoping I could undo the undo but instead I lost control and was able to undo a few steps but leaving the step that I needed to fix permanently. The history seemed to go back including the operation that I did with the layers.

If the history is meant to include every single step so some users can run timelapse (not a feature that I use) this behaviour could be controlled with a setting in preferences for all users like me who need accurate undo/redo affecting only the work inside the canvas.

In any case, the current behaviour of including the operations outside of the canvas seems to cause bugs.

Is this undo/redo behaviour expected from Vectornator? Were you guys aware of this bug? It has happened to me at least a dozen times. I will try to avoid interacting with layers when I’m expecting undo operations but I believe this limits dramatically the normal workflow of Vectornator. We should be able to do anything outside of the canvas and expect that when we return to the canvas the history is preserved and the undo/redo will respond as we need.

Can you please confirm the above?

Thank you

I’ve seen this issue and a few related ones (e.g fill lost on undo). When I contacted support, the response was:

we’re actually tracking this issue already but it’s hard to fix it because it’s caused by the system.

Thanks @llui85, I have run a few more tests and it definitely looks like it’s connected to the undo/redo functionality also saving into the history queue operations outside of the canvas. My understanding is that the undo/redo functionality is controlled inside Vectornator and not the iOS.

Hey Vectornator team, could you please advise about this bug?

@nyx I definately understand where you’re coming from; view operations probably shouldn’t affect the undo history, which they do (somewhat inconsistently) at the moment.

Part of the challenge of solving this is that it’s difficult to categorise what’s a “view” operation. For example, layer opacity is included in the image export (I think, I’m not at my iPad at the moment). It would make sense for this to be undoable - what if it was set to an important value before it was changed? As you say, this would be a good candidate for a setting.

This could also be a general design issue with the whole undo/redo concept - we tend to use the somewhat volatile undo buffer to store important data. I can’t really think of any programs that implement this well (maybe git, but that’s certainly not going to happen in Vectornator).