Issue
RenderObject lifetimes RO destroyed in Node::detach(), which is badly named.
Complications
anonymous containers continuations multicol stuff who else is pointing at you
float lists in lines continuations line boxes around inline replaced elements
Would like a WeakPtr system (but high memory cost)
Why do you use RefPtr
secondary use can hold a ref
Can we use OwnPtr?
just helps you not leak, and documents explicit ownership we don't use OwnPtrs because of RenderArenas are they still a useful opt? Need to measure
RO guard is like a debug-only RefPtr. Maybe that's how it should be implemented.
Two approaches
- Global "I'm holding a ref to some renderer, so don't destroy any". Addresses risk of being too specific
- Smart-pointer type object: RenderPtr.
(We look at some stack traces). We should protect against higher-level re-entrancy issues e.g. updating style/layout in painting.
How would we fix these?
make sure you're actually done before releasing the protector hard to avoid false positives (OK if the repaint is the last thing you're doing). The RenderPtr model has this issue.
Need to handle "zombie" renderers: need to avoid having this be a worse issue.
How to land: add the guards incrementally and fix the assertions as they are detected.
Talk about style updates and asking if things are editable. Calls from DOM require the correct answer (have to update style). Calls from other areas may be willing to avoid style updates but get the wrong answer.
Actionable things
Rename the detach() method Measure the cost of removing RenderArena
