Re: [w3c/editing] undo manager (#209)

@whsieh Ok, that is good to know. What threw me off was the note saying:

> The user agent may decide to have a separate undo history per frame. For this proposal allows WebKit's behavior, which is to have a single undo history for all browsing contexts under a single top-level browsing context.

That made it sound as if it was up to the UA whether or not it would allow more than one undo history on the same page.

How about point 1? When an undo history history is kept in JavaScript, it will basically do the following:

A. Keep a history of all document changes, and whether each of the changes is remote or local, possibly up to some max number of changes.

B. When the undo button is updated, the JS editor goes back in the undo history to see if it can find at least one local change that still could be undone. If that is the case, the button will be enabled, otherwise disabled.

C. If an enabled undo button is pressed, the JS editor goes back in the undo history and undoes the last local change that could be undone.

D. If a user undoes a change and there are remote collaborators, the user sends the change via websocket to collaborators specifying that the change Y is to cancel out previous change number X. That way the remote users know that they can skip both change X and change Y when doing B and C.

I understand that this is probably way to much complexity for the browser to engage in, but maybe there is a way to fake it? To let the JavaScript editor maintain the history and o enable/disable the undo/redo buttons whenever they need to?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/209#issuecomment-531560906