Steps to reproduce: 1. export MallocScribble=1 2. Run a debug build of Firefox. 3. Load the testcase. 4. Quit Firefox. Result: crash [@ nsAttributeTextNode::UnbindFromTree], usually dereferencing 0x555555c5, but sometimes dereferencing 0xc71fe657 or nearby.

Is this new? Sounds like a possible regression from bug 238072.

Yeah, it does.

Not blocking on this, but we'd really love a fix for this.

This should do it. Because nsAttributeTextNode is already mutationobserver, just use NodeWillBeDestroyed.

So how are we losing our grandparent _node_ without its frame (and hence us) going away?

Some property keeps element (and its attributetextnode) alive until presshell is destroyed. So could perhaps remove that property earlier.

That would be good (in addition to this patch), since otherwise we have a leak for the lifetime of the page, no?

Actually, the patch should be enough. The only case when the property doesn't get removed before grandparent is deleted is when framemanager is about to be destroyed. In that case PresShell::NotifyDestroyingFrame doesn't destroy properties for individual frames. Properties will be destroyed right after framemanager::Destroy.

Ah, ok. Can we somehow assert that we're in that situation here?

I don't think there is any easy way to assert. When properties are deleted in Destroy, document doesn't anymore have pointer to the relevant presshell.

Hmm. And we can't assert that because we don't know which shell is the relevant one, I guess. OK.

This doesn't seem to affect 1.9.0.x, and it's blamed on a bug (bug 238072) that appears to have been mozilla-central only. If I'm wrong please renominate