Is the timing of DOMContentLoaded undefined with respect to external scripts?

[a***@yahoo.com]

I thought it's supposed to be before, but it's after on a simple test page.

[Boris Zbarsky]

Post by a***@yahoo.com
I thought it's supposed to be before, but it's after on a simple test page.

DOMContentLoading fires when the parser is done parsing the document.

Some external scripts block the parser because the might issue
document.write calls.

Whether an external script blocks the parser or not depends on how it's
inserted into the DOM.

-Boris

[a***@yahoo.com]

Post by Boris Zbarsky

Post by a***@yahoo.com
I thought it's supposed to be before, but it's after on a simple test page.

DOMContentLoading fires when the parser is done parsing the document.
Some external scripts block the parser because the might issue
document.write calls.
Whether an external script blocks the parser or not depends on how it's
inserted into the DOM.

I didn't notice at first that in the page I was looking at
(www.google.com/search) the script in question is inserted in a settimeout
callback, which certainly explains the difference, from my simple
"<script>" test page.

Is it the case then that any synchronous, non deferred insertion (whether
dom or tag based) would run before DOMContentLoaded?

[Boris Zbarsky]

Post by a***@yahoo.com
Is it the case then that any synchronous, non deferred insertion (whether
dom or tag based) would run before DOMContentLoaded?

No. Only parser-inserted scripts block the parser.

-Boris

[a***@yahoo.com]

Post by Boris Zbarsky

Post by a***@yahoo.com
Is it the case then that any synchronous, non deferred insertion (whether
dom or tag based) would run before DOMContentLoaded?

No. Only parser-inserted scripts block the parser.

Just to be sure I got it:

only synchronous, non-deferred <script> tags block the parser and so run
before DOMContentLoaded.

everything else does not block and will run after DOMContentLoaded

[Henri Sivonen]

Post by a***@yahoo.com
only synchronous, non-deferred <script> tags block the parser and so run
before DOMContentLoaded.

Deferred scripts (parser-inserted <script defer src=foo.js></script>)
execute before DOMContentLoaded fires.

[a***@yahoo.com]

Post by Henri Sivonen

Post by a***@yahoo.com
only synchronous, non-deferred <script> tags block the parser and so run
before DOMContentLoaded.

Deferred scripts (parser-inserted <script defer src=foo.js></script>)
execute before DOMContentLoaded fires.

I'm not seeing this (Fx 7.0b6):
___________________________________
<script>
function handler(e) {
console.log(e.type + ':' + e.target);
}
document.addEventListener('load', handler, true);
document.addEventListener('DOMContentLoaded', handler, false);
</script>
<script defer src="script.js"></script>
___________________________________

both the script itself and its load handler log after 'DOMContentLoaded'

Should it be before? Why?

[Boris Zbarsky]

Post by a***@yahoo.com
both the script itself and its load handler log after 'DOMContentLoaded'

Works correctly over here (script load fires before DOMContentLoaded).

Post by a***@yahoo.com
Should it be before?

Yes.

Post by a***@yahoo.com
Why?

Because the spec says so?

-Boris

[a***@yahoo.com]

Post by Boris Zbarsky

Post by a***@yahoo.com
both the script itself and its load handler log after 'DOMContentLoaded'

Works correctly over here (script load fires before DOMContentLoaded).

Post by a***@yahoo.com
Should it be before?

Yes

I am running my test in a new profile with the latest nightly as well, on xp
sp3, and it's consistently after:

[14:28:01.433] GET defer.htm [HTTP/1.1 200 OK 0ms]
[14:28:01.586] DOMContentLoaded:[object HTMLDocument] @ defer.htm:3
[14:28:01.641] GET script.js [HTTP/1.1 200 OK 0ms]
[14:28:01.663] external @ script.js:1
[14:28:01.671] load:[object HTMLScriptElement] @ defer.htm:3

What do you make of this? Should I file a bug?

Post by Boris Zbarsky

Post by a***@yahoo.com
Why?

Because the spec says so?

Where? It doesn't make sense in light of what you've said:

"Some external scripts block the parser because the might issue
document.write calls."

but a deferred script can't write to the doc:

[14:20:16.461] A call to document.write() from an asynchronously-loaded
external script was ignored. @ defer.htm

your documentation confirms it:

https://developer.mozilla.org/En/HTML/Element/Script
defer
This Boolean attribute is set to indicate to a browser that the script is
meant to be executed after the document has been parsed. Since this feature
hasn't yet been implemented by all other major browsers, authors should not
assume that the script's execution will actually be deferred. Never call
document.write() from a defer script

so if a deferred script executes after the document has been parsed and
can't write to the doc, why should it block the parser?

[Boris Zbarsky]

Post by a***@yahoo.com
[14:28:01.641] GET script.js [HTTP/1.1 200 OK 0ms]

This is quite weird. How could the GET for that script happen _after_
DOMContentLoaded?

Post by a***@yahoo.com
"Some external scripts block the parser because the might issue
document.write calls."

There's a separate clause about deferred scripts. See
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#the-end
step 3, which comes before step 4.

Post by a***@yahoo.com
so if a deferred script executes after the document has been parsed and
can't write to the doc, why should it block the parser?

It doesn't. It explicitly blocks DOMContentLoaded, per spec above.

-Boris

[Boris Zbarsky]

It doesn't. It explicitly blocks DOMContentLoaded, per spec above.

One caveat. It's possible that we simply don't implement the spec
correctly, in which case we need a bug on that....

-Boris

[a***@yahoo.com]

Post by Boris Zbarsky

It doesn't. It explicitly blocks DOMContentLoaded, per spec above.

One caveat. It's possible that we simply don't implement the spec
correctly, in which case we need a bug on that....

Well, that's what I am seeing, but you said you can't confirm that, is that
still the case? That's the real mystery.

Here's the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=688580

[Boris Zbarsky]

Post by a***@yahoo.com
but you said you can't confirm that, is that
still the case?

Yep. Might depend on your network connection, if it's a race....

-Boris

[a***@yahoo.com]

Post by Boris Zbarsky

Post by a***@yahoo.com
but you said you can't confirm that, is that
still the case?

Yep. Might depend on your network connection, if it's a race....

My test page is on a web server on localhost.

[a***@yahoo.com]

Post by Boris Zbarsky

Post by a***@yahoo.com
but you said you can't confirm that, is that
still the case?

Yep. Might depend on your network connection, if it's a race....

Are you loading the test page as file://? That does not manifest the bug
for me, but http: on localhost or a different lan host, does.

[Boris Zbarsky]

Post by a***@yahoo.com
Are you loading the test page as file://?

Ah, I might have been.

-Boris

[a***@yahoo.com]

Post by Boris Zbarsky

Post by a***@yahoo.com
Are you loading the test page as file://?

Ah, I might have been.

Have you since tried over http?

[Boris Zbarsky]

Post by a***@yahoo.com
Have you since tried over http?

What's the point? Clearly there's a race.

-Boris

[a***@yahoo.com]

Post by Boris Zbarsky

Post by a***@yahoo.com
Have you since tried over http?

What's the point?

To confirm bug 688580.

I would be happy to NEW my bugs myself, but I don't have those rights.