515941 - [HTML5] Release script-removed parser-inserted nodes that aren't on the tree builder stack

Status: NEW

(Core :: DOM: HTML Parser, defect, P3)

Description

[Henri Sivonen (:hsivonen)]

Considering comet use cases, the parser shouldn't keep alive nodes that a script has removed from the DOM and that aren't any longer on the parser stack.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

So are there any technical problem to just not fix this?

Comment 2

[Henri Sivonen (:hsivonen)]

Fixing this would involve writing a special-purpose garbage collector for the content handles making it works so that it works right with two threads involved but without locking the threads too much.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Could the mainthread/cycle collector thread lock parser thread occasionally and
traverse/unlink something in the parser thread?
CC doesn't happen too often. And hopefully the locking could happen only for certain documents/parsers.

Also, I can still misunderstand how bad or not-bad this bug is.
Can this lead to keep some elements alive as long as the page is being parsed?

Comment 4

[Henri Sivonen (:hsivonen)]

(In reply to Olli Pettay [:smaug] from comment #3)
> Could the mainthread/cycle collector thread lock parser thread occasionally
> and traverse/unlink something in the parser thread?

Locking the world occasionally an option, but I'd implement the garbage collection as a sweep over the parser's data structures and rewriting the active handles to point to new backing storage (and then destroying the old backing storage) instead of using CC itself.

> Can this lead to keep some elements alive as long as the page is being
> parsed?

Yes. This leads to all elements created by a parser being alive as long as that parser is still active even if a script has removed the elements from the DOM.

Anyway, to answer your first question properly: The reason this hasn't been done yet is that the amount of work required to fix this is large relative to how often the problem might actually appear. After all, this is a total non-issue for the vast, vast majority of HTML documents.