1856673 - nsContentUtils::GenerateStateKey doesn't deal with dynamic DOM mutations.

Status: NEW

(Core :: DOM: Core & HTML, defect)

Description

[Emilio Cobos Álvarez [:emilio]]

Bug 1856655 is an example where we remove a DOM node, save the state of a sibling with a given index, and then restore it but look up a totally confused key.

It seems, at least for state restoration inside the same document, we could either:

• Track the state with a nsWeakPtr of the element as a key or so, maybe in addition to the string key.
• Use the ID of the element as part of the key (that'd fix that particular thing but it doesn't seem very general).

I don't think there's anything preventing us from doing something like the first tho... Olli am I missing something that would make it hard?

To be clear the idea would be to store both {weakptr, string} as the hash map key, and looking using {nsIContent*, string}. If the weakptr and the nsIContent pointer matches, then that's a match, regardless of whether the strings match.

Or something along those lines. SessionRestore would only store the string keys as it does now.