DOMContentLoaded is not fired when calling document.close()

NEW
Assigned to

Status

()

defect
P3
normal
7 years ago
11 months ago

People

(Reporter: blizzard, Assigned: smaug)

Tracking

Trunk
x86_64
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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.
Henri, could you look into this?
Assignee: nobody → hsivonen
(In reply to Johnny Stenback (:jst, jst@mozilla.com) from comment #1)
> Henri, could you look into this?

OK. Curiously, bug 715112 isn't enough to fix this.
Depends on: 715112
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.)
Assignee: hsivonen → nobody
Depends on: 635548
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.
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.
(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.
> 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.
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.)
Is that a feature or a bug?
(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.
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...
Assignee: nobody → bugs
Henri, assign this to me if you don't have time to look at this.
Assignee: bugs → 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.
Assignee: hsivonen → bugs
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.

Updated

11 months ago
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.