As far as I can tell, nsPopupSetFrame takes an nsIFrame* list, stores those frames in popup entries, then forgets about the fact that the frames are linked to each other. This is not a problem per se, except that nsPopupSetFrame::RemoveFrame will destroy the frame without removing the link to it from its previous sibling. After that, we have pointers to dead memory that we're liable to make virtual function calls on... We're sort of saved right now by not exposing nsGkAtoms::popupList, I think, which means that we don't just crash and burn all over on every test run. But I'm not happy depending on that, of course, and I have no guarantee that this can't be crashed. The right thing to do is to fix things so we don't have those dangling pointers.

We've fixed the dangling pointers in bug 529371. However, I don't see why nsPopupSetFrame needs the setup it has. Can't it just use a regular framelist instead of the custom linked-list it currently uses?

Does this still need to be security-sensitive?

Is it a problem on older branches? bug 529371 was marked as a regression, but it wasn't clear from what and your comment 0 doesn't sound like a new condition.

Possibly via the accessibility issue we just addressed, yes.

meaning bug 529371 or bug 529442? both?

both

I think Neil agreed we should use a regular framelist here.

I don't think there's anything security sensitive here anymore is there?

In fact, I think the this was fixed long ago by 544251.