Bug 70966 - Adopted node has a different lifetime than a parse-created node in a document
Summary: Adopted node has a different lifetime than a parse-created node in a document
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-26 13:52 PDT by Ryosuke Niwa
Modified: 2017-07-18 08:29 PDT (History)
5 users (show)

See Also:


Attachments
test (3.11 KB, application/zip)
2011-10-26 14:40 PDT, Ryosuke Niwa
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ryosuke Niwa 2011-10-26 13:52:06 PDT
When javascript adopts a node into a different frame, and then the frame into which the node was adopted navigates to a different page (e.g. by location.href), then the adopted node will be dead after the navigation even though a parse-created node in the original document is still alive.

Furthermore, behavior is different depending on how long we wait.
Comment 1 Ryosuke Niwa 2011-10-26 14:40:09 PDT
Created attachment 112596 [details]
test
Comment 2 Ojan Vafai 2011-10-26 16:28:41 PDT
The only sane behavior I can think of here is that we need to keep the frame's original document alive until the reference to the adopted node goes away.
Comment 3 Alexey Proskuryakov 2011-10-27 14:02:33 PDT
This test is quite complicated. I don't think that it's showing what the title implies, and I'm not sure if it's showing any bug.

Notably, the adopt() function is called twice - once when the document is loaded, and then again after you click a link to test. This is what resets "target" variable to null.
Comment 4 Ryosuke Niwa 2011-10-27 14:42:10 PDT
(In reply to comment #3)
> Notably, the adopt() function is called twice - once when the document is loaded, and then again after you click a link to test. This is what resets "target" variable to null.

No, if you click the one with 0 timeout, then you'll still have target variable. Only when you bump up the timeout, will you see target going away.
Comment 5 Alexey Proskuryakov 2011-10-27 15:06:15 PDT
The fact that a zero delay timer behaves differently is likely because it fires before the navigation has finished. Timing dependency doesn't necessarily mean that it's garbage collection.
Comment 6 Ryosuke Niwa 2011-10-27 15:45:23 PDT
(In reply to comment #5)
> The fact that a zero delay timer behaves differently is likely because it fires before the navigation has finished. Timing dependency doesn't necessarily mean that it's garbage collection.

It's probably to do with the timer in HTMLFrameElementBase.
Comment 7 Alexey Proskuryakov 2011-10-27 17:57:12 PDT
Could you please make a smaller reduction if you think that there is a bug here? What I see looks like correct behavior.
Comment 8 Alexey Proskuryakov 2013-01-24 22:27:44 PST
Still unsure what the issue here is, if any. But see bug 107859.