Summary of what I believe happens (not entirely verified yet): - Hide a tab, which removes the <browser> and does removeChild on the messages (<table>) to detach it from the document. - Some time later (possibly not very long) the GC knocks, and recycles the document object. This causes ownerDocument on messages and all its children to become null (violation of the DOM spec). - Next message for a hidden tab arrives, attempts to adopt into messages.ownerDocument, but it is null and this causes an error. - The error trips the code into making adoptNode a no-op. We might be able to work around the bad DOM implementation by just not calling removeChild in cmdHideView, if this is enough to force Gecko into keeping the document around. Alternatively, we can try and force the new view into existence *before* adding the newly-arrived message.
I have just verified with my debug build that if no GC occurs between hiding and a message arriving, it is fine; if a GC does occur, it breaks.
This adopts the messages into a hidden document which we forever keep a reference to (until we close), which means the nodes are no longer at risk of having null ownerDocuments.
Assignee: rginda → silver
Status: NEW → ASSIGNED
Attachment #298106 - Flags: review?(gijskruitbosch+bugs)
Comment on attachment 298106 [details] [diff] [review] Avoid null ownerDocument by adopting into controlled hidden document Don't you need to null client.hiddenDocument out at some point? (onUnload?) With that, or an explanation, r=gijs
Attachment #298106 - Flags: review?(gijskruitbosch+bugs) → review+
Checked in --> FIXED.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.