Bugzilla

(In reply to Daniel Holbert [:dholbert] from comment #9)
> Two thoughts here:
> - I'm not entirely clear on why we unlink the object in step (1) of my list above and then don't delete it until later.  Maybe that's normal? I'm not sure.

Chatting with mccr8, it sounds like this^ is a normal thing that can happen, for C++ objects that are owned by JS. (They can get unlinked in one CC and then deleted in the next GC or CC.)

Given that, I think we do need some sort of  `bool mIsInTearoffTable` guard here to nerf redundant calls to RemoveFromTearoffTable() - maybe for all of our SVG tearoffs, even (it's probably not just this one that's susceptible to this).

(In reply to Daniel Holbert [:dholbert] from comment #9)
> - I'm not entirely clear on why we unlink the object in step (1) of my list above and then don't delete it until later.  Maybe that's normal? I'm not sure.

Chatting with mccr8, it sounds like this^ is actually a normal thing that can happen, for C++ objects that are owned by JS. (They can get unlinked in one CC and then deleted in the next GC or CC.)

Given that, I think we do need some sort of  `bool mIsInTearoffTable` guard here to nerf redundant calls to RemoveFromTearoffTable() - maybe for all of our SVG tearoffs, even (it's probably not just this one that's susceptible to this).

(In reply to Daniel Holbert [:dholbert] from comment #9)
> - I'm not entirely clear on why we unlink the object in step (1) of my list above and then don't delete it until later.  Maybe that's normal? I'm not sure.

Chatting with mccr8, it sounds like this^ is actually a normal thing that can happen, for C++ objects that are owned by JS. (They can get unlinked in one CC and then deleted in the next GC or CC, with JS having an opportunity to run in between.)

Given that, I think we do need some sort of  `bool mIsInTearoffTable` guard here to nerf redundant calls to RemoveFromTearoffTable() - maybe for all of our SVG tearoffs, even (it's probably not just this one that's susceptible to this).