Bugzilla

In the pernosco session,  `mItems.Length()` is `2` whereas `InternalList().Length()` is `3`.

This happens because there are two different tearoff objects, and one of them is out of date.  The testcase has:
```
  let x = b.points
  try { FuzzingFunctions.garbageCollect() } catch (err) {}
  try { FuzzingFunctions.cycleCollect() } catch (err) {}
  let y = b.points
```
Here `x` and `y` end up with **different DOMSVGPointList objects**.

Previously they're both `2`, but `InternalList().Length()` grows to length `3` in a call to `InsertBefore()`.

It looks like this is because the tearoff table might not be sticking around for the second `b.points` call for some reason, which is why we end up generating a new `DOMSVGPointList` tearoff.

In the pernosco session,  `mItems.Length()` is `2` whereas `InternalList().Length()` is `3`.  (Previously they're both `2`, but `InternalList().Length()` grows to length `3` in a call to `InsertBefore()`, while operating on a *different* tearoff that shares the same underlying internal-list.)

This happens because there are two different tearoff objects, and one of them is out of date.  The testcase has:
```
  let x = b.points
  try { FuzzingFunctions.garbageCollect() } catch (err) {}
  try { FuzzingFunctions.cycleCollect() } catch (err) {}
  let y = b.points
```
Here `x` and `y` end up with **different DOMSVGPointList objects** having been returned from `b.points`.

It looks like this is because the tearoff table might not be sticking around for the second `b.points` call for some reason, which is why we end up generating a new `DOMSVGPointList` tearoff.

In the pernosco session,  `mItems.Length()` is `2` whereas `InternalList().Length()` is `3`.  (Previously they're both `2`, but `InternalList().Length()` grows to length `3` in a call to `InsertBefore()`, while operating on a *different* tearoff that shares the same underlying internal-list.)

This happens because there are two different tearoff objects, so one of them ends up out of date.  The testcase has:
```
  let x = b.points
  try { FuzzingFunctions.garbageCollect() } catch (err) {}
  try { FuzzingFunctions.cycleCollect() } catch (err) {}
  let y = b.points
```
Here `x` and `y` end up with **different DOMSVGPointList objects** having been returned from `b.points`.

It looks like this is because the tearoff table might not be sticking around for the second `b.points` call for some reason, which is why we end up generating a new `DOMSVGPointList` tearoff.