65407 2011-07-29 22:03:04 -0700 Webkit doesn't clear timeouts and intervals when open() is called on a document that's not already open 2011-08-28 06:44:38 -0700 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) Unspecified Unspecified NEW P2 Normal --- 1 tobbi.bugs webkit-unassigned abarth ap bzbarsky eric me oldest_to_newest 444250 0 102424 tobbi.bugs 2011-07-29 22:03:04 -0700 Created attachment 102424 testcase As per https://bugzilla.mozilla.org/show_bug.cgi?id=675399#c1 and http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#dom-document-write, calling of document.write after parsing is done should trigger a new document object to be created (please refer to that bug for proper explanation: --- You're calling document.write() after parsing is done. Per http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#dom-document-write step 3, this triggers a call to open(). Then http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#dom-document-open step 12 replaces the window associated with the document with a new window. The list of timeouts is attached to the old window, so goes away. WebKit just gets this wrong. Please report the problem to them.... --- 444949 1 102580 ap 2011-08-01 15:53:14 -0700 Created attachment 102580 updated test case That text means that the first call to document.write() after parsing is done should replace original content, and that's what happens in both WebKit And Gecko. But why does the insertion point become undefined after the first document.write()? 445033 2 bzbarsky 2011-08-01 17:43:06 -0700 The issue is not the insertion point. The issue is that the open() should clear the interval (because it sets up a new Window), but doesn't seem to in WebKit. 445100 3 ap 2011-08-01 21:44:38 -0700 Thanks, that makes sense. We don't set up a new document or window on document.open() though, we just remove all children of the existing document, and do some other cleanup. But custom properties all survive, too. This doesn't feel like a typical WebKit bug, perhaps we're matching IE or older Gecko. 445128 4 abarth 2011-08-02 00:07:33 -0700 I don't know the history of why we have the current behavior, but we should probably match other browsers. 102424 2011-07-29 22:03:04 -0700 2011-08-01 15:53:14 -0700 testcase testcase.html text/html 255 tobbi.bugs PGh0bWw+CjxoZWFkPgoJPHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPgoJZnVuY3Rpb24g aW5jcmVtZW50KCkgeyAKCQlkb2N1bWVudC53cml0ZSgiYSIpOwoJfQoKCXZhciBJRCA9IGRvY3Vt ZW50LmFkZEV2ZW50TGlzdGVuZXIoIkRPTUNvbnRlbnRMb2FkZWQiLCBmdW5jdGlvbigpIHsgd2lu ZG93LnNldEludGVydmFsKCJpbmNyZW1lbnQoKTsiLCAxMDAwKTsgfSk7Cgk8L3NjcmlwdD4KPC9o ZWFkPgo8Ym9keT4KPC9ib2R5Pgo8L2h0bWw+ 102580 2011-08-01 15:53:14 -0700 2011-08-01 15:53:14 -0700 updated test case testcase.html text/html 276 ap PGh0bWw+PGhlYWQ+Cgk8c2NyaXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCI+CglmdW5jdGlvbiBp bmNyZW1lbnQoKSB7CgkJZG9jdW1lbnQud3JpdGUoImEiKTsKCX0KCgl2YXIgSUQgPSBkb2N1bWVu dC5hZGRFdmVudExpc3RlbmVyKCJET01Db250ZW50TG9hZGVkIiwgZnVuY3Rpb24oKSB7IHdpbmRv dy5zZXRJbnRlcnZhbCgiaW5jcmVtZW50KCk7IiwgMTAwMCk7IH0sIGZhbHNlKTsKCTwvc2NyaXB0 Pgo8L2hlYWQ+Cjxib2R5PgpPcmlnaW5hbCBjb250ZW50CjwvYm9keT48L2h0bWw+