Figure out order of events around <script defer>, DOMContentLoaded, readystate etc

RESOLVED DUPLICATE of bug 688580

Status

()

Core
DOM: Core & HTML
P2
normal
RESOLVED DUPLICATE of bug 688580
9 years ago
4 years ago

People

(Reporter: Michael Dayah, Assigned: sicking)

Tracking

unspecified
mozilla1.9.1
Points:
---
Bug Flags:
blocking1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Win64; x64; .NET CLR 2.0.50727; SLCC1)
Build Identifier: 

Defer is a very nice feature. It allows us to ditch our event attachments and wrappers for onload and DOMContentLoaded and allow the browser to deal with download parallelization and execution timing.

However, due to Webkit, Firefox 3.0, and Opera, we're forced to leave part of that wrapper in for now. The way we might do that is:

if (IE || defer.supported) load_complete();
else if (addEventListener) addEventListener("DCL", load_complete);
else onload = load_complete;

To implement logic like this, we need one of two things. Either a way to detect if defer is supported, something not contained in the new 3.1 documentation, or a firing of DCL after deferred scripts are loaded. Either is fine with me. We also may want to synchronize with Webkit on event order and defer detection: https://bugs.webkit.org/show_bug.cgi?id=20710

Defer has the potential to do a lot of good. It serves as a hint that there is no document.write, which could allow further optimization, and it offloads the wrapper logic we write in to determine when a script is ready to execute to the browser, which in the future could more intelligently determine when to execute scripts.

Reproducible: Always
(Reporter)

Updated

9 years ago
Depends on: 28293
Flags: blocking1.9.1?
Assignee: nobody → jonas
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Summary: <script defer> scripts run after DOMContentLoaded → Figure out order of events around <script defer>, DOMContentLoaded, readystate etc

Updated

9 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
We do now actually fire DOMContentLoaded after deferred scripts. However I'd like to investigate more which order we should do things so it might change back. I do agree that we need to support the pattern in comment 0, in one way or another.
Jonas, had a chance to investigate further here?
So since we've decided to stay with firing DOMContentLoaded after deferred scripts have executed I'd say there is nothing left to do that is blocking. So closing this bug.

However I do think that we should fire an event after the DOM is parsed but before we've evaluated deferred scripts though (since they can be external). That isn't blocking though so I'll file a new bug on that.

Updated

9 years ago
Target Milestone: --- → mozilla1.9.1
Closing bug as invalid (due to lack of a better resolution here) per previous comment as there's nothing left to do, and as I'm sure Jonas meant to do when he last commented.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID
(Reporter)

Comment 5

8 years ago
It appears that in 3.6, DOMContentLoaded is now firing before deferred scripts.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---

Comment 6

8 years ago
This appears to be because of https://bugzilla.mozilla.org/show_bug.cgi?id=518104
(In reply to Michael Dayah from comment #5)
> It appears that in 3.6, DOMContentLoaded is now firing before deferred
> scripts.

Dup of bug 688580?

(In reply to anthonyryan1 from comment #6)
> This appears to be because of
> https://bugzilla.mozilla.org/show_bug.cgi?id=518104

Shouldn't be, the desc here status the patch there was to simply not honoring deter attribute for a inline script block (w/o src), and the handling of document.write().
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 688580
You need to log in before you can comment on or make changes to this bug.