GitLab

SerializeNodeChanges() checks every descendant node to see if it was
reparented, which is considered an error condition, because reparented
nodes should be handled in the caller SerializeChanges(). When this
error condition is reached, it means that the helper
AnyDescendantWasReparented() did not detect a reparented node, and the
tree is Reset() -- meaning it will need to be rebuilt. In addition,
generated events on reparented nodes will be lost.

This error condition occurred when nodes change their ignored status,
because of a line in AnyDescendantWasReparented() that causes it to skip
checking children recursively for valid nodes. Skipping this check when
node is ignored avoids the error condition.

In addition, a DumpWithoutCrashing() calls is added so that the
accessibility team can understand how often this error condition occurs.

This change has the side effect of detecting more reparenting changes,
because when a subtree becomes display:none, a new accessible is
created for each node in the subtree -- unless one of the objects in
the subtree was already display:none. Those nodes will effectively
get new parents. As a result of this side effect, menupopupend
changes need to be fired on any menu nodes that are deleted,
not just when they're the root of a subtree that's deleted. This is
a more robust solution for menupopupend events in any case.

Bug: 1059394
Change-Id: I0433690d6f7ac9708bcc54dafe4b3f9b09d30ee5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2090736
Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#751870}