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

[al...@yahoo.com]

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

[Boris Zbarsky]

On 9/21/11 11:07 PM, al...@yahoo.com wrote:
> 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

[al...@yahoo.com]

"Boris Zbarsky" <bzba...@mit.edu> wrote in message
news:B-adnd_q7bYmLefT...@mozilla.org...

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]

On 9/22/11 12:25 AM, al...@yahoo.com wrote:
> 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

[al...@yahoo.com]

"Boris Zbarsky" <bzba...@mit.edu> wrote in message

news:FOadnd1n4LgwX-fT...@mozilla.org...

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]

On Thu, Sep 22, 2011 at 8:42 AM, <al...@yahoo.com> wrote:
> 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.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

[al...@yahoo.com]

"Henri Sivonen" <hsiv...@iki.fi> wrote in message
news:mailman.10654.1316672...@lists.mozilla.org...

> On Thu, Sep 22, 2011 at 8:42 AM, <al...@yahoo.com> wrote:
>> 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]

On 9/22/11 4:59 AM, al...@yahoo.com wrote:
> both the script itself and its load handler log after 'DOMContentLoaded'

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

> Should it be before?

Yes.

> Why?

Because the spec says so?

-Boris

[al...@yahoo.com]

"Boris Zbarsky" <bzba...@mit.edu> wrote in message

news:ONmdnbCEWI27p-bT...@mozilla.org...

> On 9/22/11 4:59 AM, al...@yahoo.com wrote:
>> both the script itself and its load handler log after 'DOMContentLoaded'
>
> Works correctly over here (script load fires before DOMContentLoaded).
>
>> 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?

>
>> 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]

On 9/22/11 2:33 PM, al...@yahoo.com wrote:
> [14:28:01.586] DOMContentLoaded:[object HTMLDocument] @ defer.htm:3
> [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?

> 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:

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.

> 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]

On 9/22/11 2:59 PM, Boris Zbarsky wrote:
> 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

[al...@yahoo.com]

"Boris Zbarsky" <bzba...@mit.edu> wrote in message

news:5LKdnSi3BdFYGubT...@mozilla.org...

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]

On 9/22/11 3:54 PM, al...@yahoo.com wrote:
> 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

[al...@yahoo.com]

"Boris Zbarsky" <bzba...@mit.edu> wrote in message

news:7tmdndJBo8nLCebT...@mozilla.org...

My test page is on a web server on localhost.

[al...@yahoo.com]

"Boris Zbarsky" <bzba...@mit.edu> wrote in message

news:7tmdndJBo8nLCebT...@mozilla.org...

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]

On 9/22/11 5:16 PM, al...@yahoo.com wrote:
> Are you loading the test page as file://?

Ah, I might have been.

-Boris

[al...@yahoo.com]

"Boris Zbarsky" <bzba...@mit.edu> wrote in message

news:EdCdnXI4uPR4OubT...@mozilla.org...

> On 9/22/11 5:16 PM, al...@yahoo.com wrote:
>> Are you loading the test page as file://?
>
> Ah, I might have been.
>

Have you since tried over http?

[Boris Zbarsky]

On 9/23/11 6:40 PM, al...@yahoo.com wrote:
> Have you since tried over http?

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

-Boris

[al...@yahoo.com]

"Boris Zbarsky" <bzba...@mit.edu> wrote in message

news:p_ydnRMVZtHQpODT...@mozilla.org...

> On 9/23/11 6:40 PM, al...@yahoo.com wrote:
>> 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.