651465 - Replacing document with document.write() does not clear timeouts, causes inconsistent behavior

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Wladimir Palant]

Attachment: Testcase with the event handler not inlined

If a page calls document.write() after the page loads the current document will be replaced. It seems that in Firefox 4 this will no longer clear the timeouts defined for the previous document.

Steps to reproduce:

* Open the attached test page (the one with the event handler not inlined)

Expected results:

The page text says "replaced text" and no alert message appears (timeout doesn't fire), also no error message in Error Console (like in Firefox 3.6, MSIE and Opera). Note: Chrome and Safari behave differently and allow the timeout to fire, an alert message is shown there.

Actual results:

Firefox attempts to execute the timeout but fails with "attempt to run compile-and-go script on a cleared scope" error message (visible in Error Console). Not sure whether this is related to bug 635548.

Reproduced in Firefox 4.0 and current mozilla-central nightly (build 20110419) on Windows 7 x64.

Comment 1

[Wladimir Palant]

Attachment: Testcase with the event handler inlined

Second testcase is slightly different - the event handler is inlined, for some reason it prevents the error and the timeout actually fires (an alert message is shown like in Chrome or Safari). The second alert message says "window.test == undefined", this indicates that the timeout runs in a new scope which is empty (that's not the case for Chrome and Safari, there the timeout runs in the same scope and the message says "window test == set").

Comment 2

[Benjamin Smedberg]

This seems bad...

Comment 3

[Boris Zbarsky [:bzbarsky]]

Sure, but it's a duplicate of the general "we clear the scope" thing.

The "right" behavior here is to run the timeout, imo (as we do now).  The fact that we can't actually manage to run it is due to the JS_ClearScope and the fact that our jits can't handle it.  Which is bug 635548, as far as I can tell.

Comment 4

[Liviu Cirdei]

User Agent 	Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID 	20160524030227

I've tested this on latest Nightly (49.0a1):

*Testcase with the event handler not inlined - the event fires (an alert appears) and no error is shown in console

*Testcase with the event handler inlined - still behaves as described in comment 1.

Comment 5

[Wladimir Palant]

Yes, the behavior is mostly consistent with Chrome and Safari now - replacing the document via document.write() doesn't prevent timeouts from executing. Scope is still being cleared however, Chrome and Safari don't do that. Not sure whether this still warrants keeping this bug open.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> Scope is still being cleared however, Chrome and Safari don't do that.

We're doing what the spec says to do here.

Comment 7

[Wladimir Palant]

I read https://www.w3.org/TR/html5/webappapis.html#dom-document-open but I must be missing something. Feel free to add a pointer to the exact part of the spec saying that and resolve as WORKSFORME.

Comment 8

[Boris Zbarsky [:bzbarsky]]

https://html.spec.whatwg.org/multipage/webappapis.html#dom-document-open steps 15 to 18.

Comment 9

[Boris Zbarsky [:bzbarsky]]

I guess that's all lumped under step 15 in the fork you linked to.

Comment 10

[Wladimir Palant]

The way I see it, it's rather the W3C spec and the WHATWG spec disagreeing as far as clearing the scope is concerned - which explains different behavior in different browsers. Well, luckily I don't need to care about this mess...

Comment 11

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

W3C HTML is pretty clear
"Replace the Document's singleton objects with new instances of those objects. (This includes in particular the Window,..."
WhatWG HTML then actually defines how that is supposed to be done.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Yeah.  The reason behavior is different in different browsers is that browsers aren't very good about actually implementing the HTML spec.