413125 - Messages in hidden tabs break adoptNode wrapper forever

Status: RESOLVED FIXED

(Other Applications :: ChatZilla, defect)

Description

[James Ross]

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.

Comment 1

[James Ross]

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.

Comment 2

[James Ross]

Attachment: Avoid null ownerDocument by adopting into controlled hidden document

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.

Comment 3

[:Gijs (he/him)]

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

Comment 4

[James Ross]

Checked in --> FIXED.