Fix (Whiteboards): History issues

[sprocketc]

Is some cases we had to persist a new state by replacing the last history entry, instead of pushing a new one.
The related block was removed here https://github.com/logseq/logseq/pull/7786/files#diff-f8d520c32e2ccdf12b14a130b819d3ecbc21284ceabab9ac1ed48d2cab65f272L68-L70

As a result, calling app.persist(true), disregards the boolean and always pushes a new entry. For example, if you drag and drop a block into the canvas and then undo the action, you will notice that there are intermediate history entries that shouldn't exist. There is a similar problem with tweet shapes and iframes.

I think we can achieve a similar result by setting :whiteboard/transact? to false and by using the existing :compute-new-refs? that seems to swap the data of the last undo entry.

Fixed another bug (d3cd17e) that didn't allow us to undo a block/page creation by using the portal tool or by double clicking. The issue was accidentally fixed by #7786, because replace stopped working. The problem was that the first persist was called with replace true (so not undoable). The next one was called with replace false, but the portal element was already part of the state.

Also fixed persisting the collapsed state of portals and added tests for the mentioned cases.

Some notes about history

• I think we need to eliminate both replace and pause/resume on whiteboards. Since we have to explicitly call persist, we should be able to avoid those quirks by persisting only when needed.
• Having a shared history stack for all pages under the same repo, can lead to perceived data loss. This can be overstated on Whiteboards, because the canvas feels like a completely different context. You might add something to a whiteboard, navigate to a different page, make some changes, spam the undo and loose the changes on the whiteboard without noticing. Ideally, we should have a dedicated history per page. Clearing the stack when we navigate could help, but it could also end up being annoying.
• Persisting to edn on undo/redo seems to behave inconsistently.

[sprocketc]

Unrelated to this PR, but this test was sporadically failing.

[tiensonqin]

Works as described! 👍

[tiensonqin]

I think we need to eliminate both replace and pause/resume on whiteboards. Since we have to explicitly call persist, we should be able to avoid those quirks by persisting only when needed.

It'll be great if we can remove both replace and pause/resume.

You might add something to a whiteboard, navigate to a different page, make some changes, spam the undo and loose the changes on the whiteboard without noticing.

Outliner pages share this problem too, we need a way to prevent the undo/redo if the history is not related to the current operating pages.

Persisting to edn on undo/redo seems to behave inconsistently.

Can you create an issue on it?

[sprocketc]

Outliner pages share this problem too, we need a way to prevent the undo/redo if the history is not related to the current operating pages.

@tiensonqin Working on a fix here #8816

Can you create an issue on it?

Will do, once I figure out how to reproduce this consistently.

[logseq-cldwalker]

@sprocketc Thanks for the fixes with tests! 🐛 🔥 Confirmed tests behave as desired