User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0 Build ID: 20151110004043 Steps to reproduce: 1. Rename tag 2. Try to undo changes Reference to client/markupview/markup-view.js: https://dxr.mozilla.org/mozilla-central/source/devtools/client/markupview/markup-view.js#2954 Actual results: Undo isn't happening. Expected results: Tag should be backed to its initial value.

From bug 1221183 comment 21: > If we change attribute, rename tag and then undo - there is an error as was before with attributes > and tag change at the same time and then undo. Somehow we should change node after creating > actions in doMods / undoMods.

(In reply to Grisha Pushkov from comment #1) > From bug 1221183 comment 21: > > If we change attribute, rename tag and then undo - there is an error as was before with attributes > > and tag change at the same time and then undo. Somehow we should change node after creating > > actions in doMods / undoMods. This is getting complicated. Basically, anytime we want to undo something on a node that was deleted/re-created, this will happen. If you changed a node's attributes, and then edited it as HTML, or deleted it, or changed its tagname, we would have to somehow track some reference to this node so that if you went back in history, we'd be able to know which node needs to have its attributes changed. For instance: 1 - change node's attributes 2 - delete node 3 - undo (which would re-create the node by actually appending a new one) 4 - undo (which should revert the attribute changes, but on the new node, the original one was deleted). Or whenever a node is deleted/changed in the inspector, we make sure to keep a reference to it so it doesn't get garbage collected, so we can actually re-append the same one later on undo. What that means however, is that we would need to move the whole undo/redo logic to the server (in devtools/server/actors/inspector.js). I think it makes more sense for it to live there anyway, but that's a much larger project. In the meantime, I think we could still implement tag edit undo client-side, by reusing the same doMods/undoMods system we have today. But whenever a node gets its tag changed, we should perhaps reset the undo stack for this node, so that there's no risk of trying to undo an attribute change on a deleted node.

> But whenever a node gets its tag changed, we should perhaps reset the undo stack for this node, so that > there's no risk of trying to undo an attribute change on a deleted node. And now I get the reason for existence of those try / catches, that I removed in bug 994555 (bug 994555 comment 30).

Triaging (filter on CLIMBING SHOES).