719285 - DOMContentLoaded is not fired when calling document.close()

Status: NEW

(Core :: DOM: Events, defect, P3)

Description

[Christopher Blizzard (:blizzard)]

Attachment: test case for document.close() interactions with DOMContentLoaded

When you call document.close() after calling .open() on your own document we don't fire the DOMContentLoaded event.  IE9 and Chrome do appear to do this, and according to jst we want to be doing so.

Simple test case attached.

Comment 1

[Johnny Stenback (:jst)]

Henri, could you look into this?

Comment 2

[Henri Sivonen (:hsivonen)]

(In reply to Johnny Stenback (:jst, [e-mail]) from comment #1)
> Henri, could you look into this?

OK. Curiously, bug 715112 isn't enough to fix this.

Comment 3

[Henri Sivonen (:hsivonen)]

With the patch for bug 715112, DOMContentLoaded gets fired, but the JS-based event handler fails to run due to "attempt to run compile-and-go script on a cleared scope" (bug 635548 AFAICT).

Either this bug needs to just wait for bug 635548 or this needs an owner who knows about JS scope clearing. (I don't.)

Comment 4

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

Hmm, secondload is defined in the first window. document.open creates a new window so
secondload doesn't work when someone tries to call it in the second window.
I'm not sure what the spec says about this case, if it says anything.

This is all about our (inner) window handling, and a lot less about document parsing.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Yeah, we should check what the spec says and what other browsers do.  WebKit has known bugs where they don't clear out the window correctly on document.open (e.g. leave event listeners hanging around in some cases), so the testcase might just be working there by accident.

I don't think bug 635548 has anything to do with this bug.

Comment 6

[Henri Sivonen (:hsivonen)]

(In reply to Olli Pettay [:smaug] from comment #4)
> Hmm, secondload is defined in the first window. document.open creates a new
> window so
> secondload doesn't work when someone tries to call it in the second window.

The function is created in the first window but it's set as a listener after the second window has been created (so .open() doesn't blow it away). The windows are same-origin, so intuitively, I would have expected the function call not to get blocked by "attempt to run compile-and-go script on a cleared scope".

> This is all about our (inner) window handling, and a lot less about document
> parsing.

Yes.

(In reply to Boris Zbarsky (:bz) from comment #5)
> Yeah, we should check what the spec says and what other browsers do.  WebKit
> has known bugs where they don't clear out the window correctly on
> document.open (e.g. leave event listeners hanging around in some cases), so
> the testcase might just be working there by accident.

The listener is attached after .open(), so this isn't about .open() clearing handlers.

> I don't think bug 635548 has anything to do with this bug.

Bug 651465 is very similar to this bug and has also been marked dependent on bug 635548. That's why I marked this one as dependent on bug 635548.

Comment 7

[Boris Zbarsky [:bzbarsky]]

> The listener is attached after .open(), so this isn't about .open() clearing handlers.

The handlers were an example.  open() also does various other JS scope clearing, is the point.  Again, need to figure out what the spec says about this, if anything.

_If_ we have to clear the scope, then Spidermonkey currently does not support running any functions against that scope after that; hence the error you see.

Comment 8

[Henri Sivonen (:hsivonen)]

To respond to blizzard's question in my IRC scrollback: With bug 715112 fixed, the DOMContentLoaded event now fires. However, when the event handler is set the way it is set in this test case, the JS function that the event dispatch code tries to call is prevented from running due to JS scope clearing. (The error message is the one from bug 635548.)

Comment 9

[Christopher Blizzard (:blizzard)]

Is that a feature or a bug?

Comment 10

[Henri Sivonen (:hsivonen)]

(In reply to Christopher Blizzard (:blizzard) from comment #9)
> Is that a feature or a bug?

From a descriptivist point of view, it's clearly a bug, since the test case says "Success" in Opera 12, IE9 and Chrome 18.

I'm not sure if it's a bug from a prescriptivist point of view. That is, I'm not sure what the specs require. But, IMO, if the specs require the Gecko behavior instead of requiring what everyone else does, the specs are wrong.

Comment 11

[Johnny Stenback (:jst)]

Olli, could you look into this one now that bug 637099 is fixed? I.e. figure out what the spec says here and what other browsers do and either fix this in Gecko, or raise this issue with the HTML5 spec...

Comment 12

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

Henri has just spent time testing this all.
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-April/035521.html

Comment 13

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

Henri, assign this to me if you don't have time to look at this.

Comment 14

[Henri Sivonen (:hsivonen)]

(In reply to Olli Pettay [:smaug] from comment #13)
> Henri, assign this to me if you don't have time to look at this.

I don't expect to get to this in the near term.  As far as I can tell, the parser fires the event OK and the JavaScript scope management is what's preventing the event handler from running, so that's outside the area of my expertise.

Comment 15

[Thomas Wisniewski [:twisniewski]]

Perhaps this has been inadvertently fixed in the past few years? I'm seeing "success" when I try the test-case in today's nightly.