Do not re-register cached id-name HTMLCollection at same invalidation type

Do not re-register cached id-name HTMLCollection at same invalidation type.

An HTMLCollection creates an id-name cache for namedItem()/item() lookups.
To handle document tree invalidations following id-name mutations, the
HTMLCollection must then register with the document has having such a
cached collection.

This is done "by proxy", registering the HTMLCollection as being
dependent on id-name invalidation. This registration for the cache being
quite possibly in addition to the collection invalidation type that the
HTMLCollection is already registered at. The HTMLCollection implementation
then naturally taking care to unregister if the cache is invalidated and
cleared.

With Oilpan, the document keeps a weak set of references to these
live collections. So in the event that the HTMLCollection is already
an id-name collection and it registers its id-name cache (by proxy)
with the document, it will re-register the same collection object.
Upon invalidation of the id-name cache the unregistration will then
remove the HTMLCollection entirely as being dependent on id-name
related invalidation notifications. That lack of invalidations can
in certain circumstances lead to failure (see test.)

Address the problem by having id-name HTMLCollections not bother
with (un)registering the id-name cache as (another) live collection.
It adds no value, the collection object is already registered.

(This worked out non-Oilpan as the document there keeps bin counts
per collection invalidation type, allowing "duplicates" from the
same object.)

R=haraken
BUG=585054
Committed: https://crrev.com/48691755ab42b61dc11ec20cd70f2bfb0100eb8a
Cr-Commit-Position: refs/heads/master@{#374385}

[sof, 2016-02-09 13:59:57]

Description was changed from

==========
Do not re-register id-name HTMLCollection's cache.

R=
BUG=
==========

to

==========
Do not re-register cached id-name HTMLCollection at same invalidation type.

An HTMLCollection creates an id-name cache for namedItem()/item() lookups.
To handle document tree invalidations following id-name mutations, the
HTMLCollection must then register with the document has having such a
cached collection.

This is done "by proxy", registering the HTMLCollection as being
dependent on id-name invalidation. This registration for the cache being
quite possibly in addition to the collection invalidation type that the
HTMLCollection is already registered at. The HTMLCollection implementation
then naturally taking care to unregister if the cache is invalidated and
cleared.

With Oilpan, the document keeps a weak set of references to these
live collections. So in the event that the HTMLCollection is already
an id-name collection and it registers its id-name cache (by proxy)
with the document, it will re-register the same collection object.
Upon invalidation of the id-name cache the unregistration will then
remove the HTMLCollection entirely as being dependent on id-name
related invalidation notifications. That lack of invalidations can
in certain circumstances lead to failure (see test.)

Address the problem by having id-name HTMLCollections not bother
with (un)registering the id-name cache as (another) live collection.
It adds no value, the collection object is already registered.

(This worked out non-Oilpan as the document there keeps bin counts
per collection invalidation type, allowing "duplicates" from the
same object.)

R=
BUG=585054
==========

[sof, 2016-02-09 14:03:43]

sigbjornf@opera.com changed reviewers:
+ oilpan-reviews@chromium.org, tkent@chromium.org

[sof, 2016-02-09 14:03:43]

please take a look.

Took quite a while to pin down a testcase which would show up the lack of
invalidation.

[haraken, 2016-02-09 14:38:43]

Nice detective work! LGTM.

[sof, 2016-02-09 15:46:43]

Description was changed from

==========
Do not re-register cached id-name HTMLCollection at same invalidation type.

An HTMLCollection creates an id-name cache for namedItem()/item() lookups.
To handle document tree invalidations following id-name mutations, the
HTMLCollection must then register with the document has having such a
cached collection.

This is done "by proxy", registering the HTMLCollection as being
dependent on id-name invalidation. This registration for the cache being
quite possibly in addition to the collection invalidation type that the
HTMLCollection is already registered at. The HTMLCollection implementation
then naturally taking care to unregister if the cache is invalidated and
cleared.

With Oilpan, the document keeps a weak set of references to these
live collections. So in the event that the HTMLCollection is already
an id-name collection and it registers its id-name cache (by proxy)
with the document, it will re-register the same collection object.
Upon invalidation of the id-name cache the unregistration will then
remove the HTMLCollection entirely as being dependent on id-name
related invalidation notifications. That lack of invalidations can
in certain circumstances lead to failure (see test.)

Address the problem by having id-name HTMLCollections not bother
with (un)registering the id-name cache as (another) live collection.
It adds no value, the collection object is already registered.

(This worked out non-Oilpan as the document there keeps bin counts
per collection invalidation type, allowing "duplicates" from the
same object.)

R=
BUG=585054
==========

to

==========
Do not re-register cached id-name HTMLCollection at same invalidation type.

An HTMLCollection creates an id-name cache for namedItem()/item() lookups.
To handle document tree invalidations following id-name mutations, the
HTMLCollection must then register with the document has having such a
cached collection.

This is done "by proxy", registering the HTMLCollection as being
dependent on id-name invalidation. This registration for the cache being
quite possibly in addition to the collection invalidation type that the
HTMLCollection is already registered at. The HTMLCollection implementation
then naturally taking care to unregister if the cache is invalidated and
cleared.

With Oilpan, the document keeps a weak set of references to these
live collections. So in the event that the HTMLCollection is already
an id-name collection and it registers its id-name cache (by proxy)
with the document, it will re-register the same collection object.
Upon invalidation of the id-name cache the unregistration will then
remove the HTMLCollection entirely as being dependent on id-name
related invalidation notifications. That lack of invalidations can
in certain circumstances lead to failure (see test.)

Address the problem by having id-name HTMLCollections not bother
with (un)registering the id-name cache as (another) live collection.
It adds no value, the collection object is already registered.

(This worked out non-Oilpan as the document there keeps bin counts
per collection invalidation type, allowing "duplicates" from the
same object.)

R=haraken
BUG=585054
==========

[sof, 2016-02-09 15:47:29]

The CQ bit was checked by sigbjornf@opera.com

[commit-bot: I haz the power, 2016-02-09 15:47:52]

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

[commit-bot: I haz the power, 2016-02-09 15:53:53]

Description was changed from

==========
Do not re-register cached id-name HTMLCollection at same invalidation type.

An HTMLCollection creates an id-name cache for namedItem()/item() lookups.
To handle document tree invalidations following id-name mutations, the
HTMLCollection must then register with the document has having such a
cached collection.

This is done "by proxy", registering the HTMLCollection as being
dependent on id-name invalidation. This registration for the cache being
quite possibly in addition to the collection invalidation type that the
HTMLCollection is already registered at. The HTMLCollection implementation
then naturally taking care to unregister if the cache is invalidated and
cleared.

With Oilpan, the document keeps a weak set of references to these
live collections. So in the event that the HTMLCollection is already
an id-name collection and it registers its id-name cache (by proxy)
with the document, it will re-register the same collection object.
Upon invalidation of the id-name cache the unregistration will then
remove the HTMLCollection entirely as being dependent on id-name
related invalidation notifications. That lack of invalidations can
in certain circumstances lead to failure (see test.)

Address the problem by having id-name HTMLCollections not bother
with (un)registering the id-name cache as (another) live collection.
It adds no value, the collection object is already registered.

(This worked out non-Oilpan as the document there keeps bin counts
per collection invalidation type, allowing "duplicates" from the
same object.)

R=haraken
BUG=585054
==========

to

==========
Do not re-register cached id-name HTMLCollection at same invalidation type.

An HTMLCollection creates an id-name cache for namedItem()/item() lookups.
To handle document tree invalidations following id-name mutations, the
HTMLCollection must then register with the document has having such a
cached collection.

This is done "by proxy", registering the HTMLCollection as being
dependent on id-name invalidation. This registration for the cache being
quite possibly in addition to the collection invalidation type that the
HTMLCollection is already registered at. The HTMLCollection implementation
then naturally taking care to unregister if the cache is invalidated and
cleared.

With Oilpan, the document keeps a weak set of references to these
live collections. So in the event that the HTMLCollection is already
an id-name collection and it registers its id-name cache (by proxy)
with the document, it will re-register the same collection object.
Upon invalidation of the id-name cache the unregistration will then
remove the HTMLCollection entirely as being dependent on id-name
related invalidation notifications. That lack of invalidations can
in certain circumstances lead to failure (see test.)

Address the problem by having id-name HTMLCollections not bother
with (un)registering the id-name cache as (another) live collection.
It adds no value, the collection object is already registered.

(This worked out non-Oilpan as the document there keeps bin counts
per collection invalidation type, allowing "duplicates" from the
same object.)

R=haraken
BUG=585054
==========

[commit-bot: I haz the power, 2016-02-09 15:53:54]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-02-09 15:54:57]

Description was changed from

==========
Do not re-register cached id-name HTMLCollection at same invalidation type.

An HTMLCollection creates an id-name cache for namedItem()/item() lookups.
To handle document tree invalidations following id-name mutations, the
HTMLCollection must then register with the document has having such a
cached collection.

This is done "by proxy", registering the HTMLCollection as being
dependent on id-name invalidation. This registration for the cache being
quite possibly in addition to the collection invalidation type that the
HTMLCollection is already registered at. The HTMLCollection implementation
then naturally taking care to unregister if the cache is invalidated and
cleared.

With Oilpan, the document keeps a weak set of references to these
live collections. So in the event that the HTMLCollection is already
an id-name collection and it registers its id-name cache (by proxy)
with the document, it will re-register the same collection object.
Upon invalidation of the id-name cache the unregistration will then
remove the HTMLCollection entirely as being dependent on id-name
related invalidation notifications. That lack of invalidations can
in certain circumstances lead to failure (see test.)

Address the problem by having id-name HTMLCollections not bother
with (un)registering the id-name cache as (another) live collection.
It adds no value, the collection object is already registered.

(This worked out non-Oilpan as the document there keeps bin counts
per collection invalidation type, allowing "duplicates" from the
same object.)

R=haraken
BUG=585054
==========

to

==========
Do not re-register cached id-name HTMLCollection at same invalidation type.

An HTMLCollection creates an id-name cache for namedItem()/item() lookups.
To handle document tree invalidations following id-name mutations, the
HTMLCollection must then register with the document has having such a
cached collection.

This is done "by proxy", registering the HTMLCollection as being
dependent on id-name invalidation. This registration for the cache being
quite possibly in addition to the collection invalidation type that the
HTMLCollection is already registered at. The HTMLCollection implementation
then naturally taking care to unregister if the cache is invalidated and
cleared.

With Oilpan, the document keeps a weak set of references to these
live collections. So in the event that the HTMLCollection is already
an id-name collection and it registers its id-name cache (by proxy)
with the document, it will re-register the same collection object.
Upon invalidation of the id-name cache the unregistration will then
remove the HTMLCollection entirely as being dependent on id-name
related invalidation notifications. That lack of invalidations can
in certain circumstances lead to failure (see test.)

Address the problem by having id-name HTMLCollections not bother
with (un)registering the id-name cache as (another) live collection.
It adds no value, the collection object is already registered.

(This worked out non-Oilpan as the document there keeps bin counts
per collection invalidation type, allowing "duplicates" from the
same object.)

R=haraken
BUG=585054

Committed: https://crrev.com/48691755ab42b61dc11ec20cd70f2bfb0100eb8a
Cr-Commit-Position: refs/heads/master@{#374385}
==========

[commit-bot: I haz the power, 2016-02-09 15:54:58]

Patchset 2 (id:??) landed as
https://crrev.com/48691755ab42b61dc11ec20cd70f2bfb0100eb8a
Cr-Commit-Position: refs/heads/master@{#374385}