Correctly ignore AXTree event creation change state for reparented nodes

Correctly ignore AXTree event creation change state for reparented nodes

When updating an AXTree with a node_id_to_clear, we were adding a node created change for nodes that were removed, then created (a "recreation"). In the source tree though, however, the node was simply reparented (see test).

During deserialization, we first destroyed the node subtree; then, we updated nodes; finally, we sent node created/changed/subtree created based on the update node calls.

In order to detect this case at the unserialized tree phase of the update, introduce a vector to keep track of all nodes removed. A created node is then a new node that is not also a removed node.

Furthermore, a onNodeDataWillChange should not be called for newly created or reparented nodes. This is because during node updates, a node and its *children* are built. The children are not yet populated with data. As a result, we often called onNodeDataWillChange on nodes whose previous data is simply not yet initialized. This caused erroneous tree text change events.

TEST=accessibility_unittest, read Google Docs menus in ChromeVox
BUG=602056
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation

Committed: https://crrev.com/54e747470a4de1c2437556581c3a1abd63e6a423
Cr-Commit-Position: refs/heads/master@{#394267}

[David Tseng, 2016-05-16 19:44:52]

Description was changed from

==========
Fix AXTree event creation change state on reparaenting.
==========

to

==========
Fix AXTree event creation change state on reparaenting.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

[David Tseng, 2016-05-16 19:50:29]

Description was changed from

==========
Fix AXTree event creation change state on reparaenting.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

to

==========
Correctly ignore AXTree event creation change state for reparented nodes

When updating an AXTree with a node_id_to_clear, we were adding a node created
change for nodes that were removed, then created (a "recreation"). In the source
tree though, however, the node was simply reparented (see test).

In order to detect this case at the unserialized tree phase of the update,
introduce a vector to keep track of all nodes removed. A created node is then a
new node that is not also a removed node.

TEST=accessibility_unittest
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

[David Tseng, 2016-05-16 19:50:29]

dtseng@chromium.org changed reviewers:
+ dmazzoni@chromium.org

[David Tseng, 2016-05-16 19:51:36]

Description was changed from

==========
Correctly ignore AXTree event creation change state for reparented nodes

When updating an AXTree with a node_id_to_clear, we were adding a node created
change for nodes that were removed, then created (a "recreation"). In the source
tree though, however, the node was simply reparented (see test).

In order to detect this case at the unserialized tree phase of the update,
introduce a vector to keep track of all nodes removed. A created node is then a
new node that is not also a removed node.

TEST=accessibility_unittest
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

to

==========
Correctly ignore AXTree event creation change state for reparented nodes

When updating an AXTree with a node_id_to_clear, we were adding a node created
change for nodes that were removed, then created (a "recreation"). In the source
tree though, however, the node was simply reparented (see test).

In order to detect this case at the unserialized tree phase of the update,
introduce a vector to keep track of all nodes removed. A created node is then a
new node that is not also a removed node.

TEST=accessibility_unittest, read Google Docs menus in ChromeVox
BUG=602056
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

[David Tseng, 2016-05-16 23:20:47]

Description was changed from

==========
Correctly ignore AXTree event creation change state for reparented nodes

When updating an AXTree with a node_id_to_clear, we were adding a node created
change for nodes that were removed, then created (a "recreation"). In the source
tree though, however, the node was simply reparented (see test).

In order to detect this case at the unserialized tree phase of the update,
introduce a vector to keep track of all nodes removed. A created node is then a
new node that is not also a removed node.

TEST=accessibility_unittest, read Google Docs menus in ChromeVox
BUG=602056
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

to

==========
Correctly ignore AXTree event creation change state for reparented nodes

When updating an AXTree with a node_id_to_clear, we were adding a node created
change for nodes that were removed, then created (a "recreation"). In the source
tree though, however, the node was simply reparented (see test).

During deserialization, we first destroyed the node subtree; then, we updated
nodes; finally, we sent node created/changed/subtree created based on the update
node calls.

In order to detect this case at the unserialized tree phase of the update,
introduce a vector to keep track of all nodes removed. A created node is then a
new node that is not also a removed node.

Furthermore, a onNodeDataWillChange should not be called for newly created or
reparented nodes. This is because during node updates, a node and its *children*
are built. The children are not yet populated with data. As a result, we often
called onNodeDataWillChange on nodes whose previous data is simply not yet
initialized. This caused erroneous tree text change events.

TEST=accessibility_unittest, read Google Docs menus in ChromeVox
BUG=602056
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

[dmazzoni, 2016-05-17 16:53:20]

lgtm

lgtm, but could you create new change types AXTreeDelegate::NODE_REPARENTED and
AXTreeDelegate::SUBTREE_REPARENTED so we have the option of handling them in the
future?

[David Tseng, 2016-05-17 19:13:14]

The CQ bit was checked by dtseng@chromium.org

[David Tseng, 2016-05-17 19:13:14]

The patchset sent to the CQ was uploaded after l-g-t-m from
dmazzoni@chromium.org
Link to the patchset: https://codereview.chromium.org/1978373002/#ps60001
(title: "Add subtree and node reparented.")

[commit-bot: I haz the power, 2016-05-17 19:13:47]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1978373002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1978373002/60001

[commit-bot: I haz the power, 2016-05-17 23:20:39]

Description was changed from

==========
Correctly ignore AXTree event creation change state for reparented nodes

When updating an AXTree with a node_id_to_clear, we were adding a node created
change for nodes that were removed, then created (a "recreation"). In the source
tree though, however, the node was simply reparented (see test).

During deserialization, we first destroyed the node subtree; then, we updated
nodes; finally, we sent node created/changed/subtree created based on the update
node calls.

In order to detect this case at the unserialized tree phase of the update,
introduce a vector to keep track of all nodes removed. A created node is then a
new node that is not also a removed node.

Furthermore, a onNodeDataWillChange should not be called for newly created or
reparented nodes. This is because during node updates, a node and its *children*
are built. The children are not yet populated with data. As a result, we often
called onNodeDataWillChange on nodes whose previous data is simply not yet
initialized. This caused erroneous tree text change events.

TEST=accessibility_unittest, read Google Docs menus in ChromeVox
BUG=602056
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

to

==========
Correctly ignore AXTree event creation change state for reparented nodes

When updating an AXTree with a node_id_to_clear, we were adding a node created
change for nodes that were removed, then created (a "recreation"). In the source
tree though, however, the node was simply reparented (see test).

During deserialization, we first destroyed the node subtree; then, we updated
nodes; finally, we sent node created/changed/subtree created based on the update
node calls.

In order to detect this case at the unserialized tree phase of the update,
introduce a vector to keep track of all nodes removed. A created node is then a
new node that is not also a removed node.

Furthermore, a onNodeDataWillChange should not be called for newly created or
reparented nodes. This is because during node updates, a node and its *children*
are built. The children are not yet populated with data. As a result, we often
called onNodeDataWillChange on nodes whose previous data is simply not yet
initialized. This caused erroneous tree text change events.

TEST=accessibility_unittest, read Google Docs menus in ChromeVox
BUG=602056
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

[commit-bot: I haz the power, 2016-05-17 23:20:40]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-05-17 23:22:23]

Description was changed from

==========
Correctly ignore AXTree event creation change state for reparented nodes

When updating an AXTree with a node_id_to_clear, we were adding a node created
change for nodes that were removed, then created (a "recreation"). In the source
tree though, however, the node was simply reparented (see test).

During deserialization, we first destroyed the node subtree; then, we updated
nodes; finally, we sent node created/changed/subtree created based on the update
node calls.

In order to detect this case at the unserialized tree phase of the update,
introduce a vector to keep track of all nodes removed. A created node is then a
new node that is not also a removed node.

Furthermore, a onNodeDataWillChange should not be called for newly created or
reparented nodes. This is because during node updates, a node and its *children*
are built. The children are not yet populated with data. As a result, we often
called onNodeDataWillChange on nodes whose previous data is simply not yet
initialized. This caused erroneous tree text change events.

TEST=accessibility_unittest, read Google Docs menus in ChromeVox
BUG=602056
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

to

==========
Correctly ignore AXTree event creation change state for reparented nodes

When updating an AXTree with a node_id_to_clear, we were adding a node created
change for nodes that were removed, then created (a "recreation"). In the source
tree though, however, the node was simply reparented (see test).

During deserialization, we first destroyed the node subtree; then, we updated
nodes; finally, we sent node created/changed/subtree created based on the update
node calls.

In order to detect this case at the unserialized tree phase of the update,
introduce a vector to keep track of all nodes removed. A created node is then a
new node that is not also a removed node.

Furthermore, a onNodeDataWillChange should not be called for newly created or
reparented nodes. This is because during node updates, a node and its *children*
are built. The children are not yet populated with data. As a result, we often
called onNodeDataWillChange on nodes whose previous data is simply not yet
initialized. This caused erroneous tree text change events.

TEST=accessibility_unittest, read Google Docs menus in ChromeVox
BUG=602056
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation

Committed: https://crrev.com/54e747470a4de1c2437556581c3a1abd63e6a423
Cr-Commit-Position: refs/heads/master@{#394267}
==========

[commit-bot: I haz the power, 2016-05-17 23:22:24]

Patchset 4 (id:??) landed as
https://crrev.com/54e747470a4de1c2437556581c3a1abd63e6a423
Cr-Commit-Position: refs/heads/master@{#394267}