Closed
Bug 474392
Opened 16 years ago
Closed 11 years ago
Figure out order of events around <script defer>, DOMContentLoaded, readystate etc
Categories
(Core :: DOM: Core & HTML, defect, P2)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
DUPLICATE
of bug 688580
mozilla1.9.1
People
(Reporter: michael, Assigned: sicking)
References
Details
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
Assignee | ||
Updated•16 years ago
|
Flags: blocking1.9.1?
Assignee | ||
Updated•16 years ago
|
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•16 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 1•16 years ago
|
||
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.
Comment 2•16 years ago
|
||
Jonas, had a chance to investigate further here?
Assignee | ||
Comment 3•16 years ago
|
||
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•16 years ago
|
Target Milestone: --- → mozilla1.9.1
Comment 4•16 years ago
|
||
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
Closed: 16 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 5•15 years ago
|
||
It appears that in 3.6, DOMContentLoaded is now firing before deferred scripts.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Comment 6•15 years ago
|
||
This appears to be because of https://bugzilla.mozilla.org/show_bug.cgi?id=518104
Comment 7•11 years ago
|
||
(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
Closed: 16 years ago → 11 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•