Closed
Bug 776529
Opened 12 years ago
Closed 12 years ago
Document stay in `interactive` state and `load` event is never dispatched
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
INVALID
People
(Reporter: ochameau, Unassigned)
References
Details
We had a report from a broken SDK addon when using one particular webpage:
http://www.plurk.com/m/t
After some investigation, I found that when loaded in a iframe (xul[type="content"] one), this particular web page stay in `interactive` state. So that DOMContentLoaded event is dispatched, but not `load` one.
Note that this web page works correctly when being loaded in a tab. document.readyState ends up switching to `complete`.
Here is a minimal testcase that can be run in scratchpad (in chrome mode):
let iframe = document.createElement("iframe");
function onload() {
// This callback is never called
Components.utils.reportError("onload");
}
iframe.addEventListener("load", onload, true);
iframe.setAttribute("type", "content");
// If you change to any other webpage, everything should work fine
iframe.setAttribute("src", "http://www.plurk.com/m/t");
document.documentElement.appendChild(iframe);
setTimeout(function () {
// The document state is still "interactive"
Components.utils.reportError("state: "+iframe.contentDocument.readyState);
iframe.parentNode.removeChild(iframe);
}, 10000);
Any idea? Can a document block itself in interactive mode somehow? Would it be a bug in this particular web page or in gecko?
|
||
Comment 1•12 years ago
|
||
(In reply to Alexandre Poirot (:ochameau) from comment #0)
> After some investigation, I found that when loaded in a iframe
> (xul[type="content"] one), this particular web page stay in `interactive`
> state. So that DOMContentLoaded event is dispatched, but not `load` one.
>
> Note that this web page works correctly when being loaded in a tab.
> document.readyState ends up switching to `complete`.
...
> Any idea? Can a document block itself in interactive mode somehow? Would it
> be a bug in this particular web page or in gecko?
I didn't debug this particular page but: A page can get stuck in the interactive state if it never finishes loading. For example, a document created using document.open() without a matching document.close() will never finish loading (including not firing DOMContentLoaded). If a document fires DOMContentLoaded but not load, the load is failing in some sense such as by the parser getting aborted by window.stop(). Browsers don't fire the 'load' event for aborted loads.
You may be interested in bug 775467.
|
Reporter | |
Comment 2•12 years ago
|
||
Thanks Henri for these usefull informations!
I ended up reducing the failing part to following google ads script. So that just loading an empty HTML document with just this script tag, won't fire load and stay in interactive state:
<script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>
I do see some usages of document.open/write without close but it seems to be used only on some iframe child elements.
I don't see any usage of stop method.
|
|
Reporter | |
Comment 3•12 years ago
|
||
After some more digging I'm now completely under ground.
Here is the minimal code which prevent going futhur than interactive state:
document.write('<iframe id="aswift_0"></iframe>');
var iframe = window.document.getElementById("aswift_0");
var doc = iframe.contentDocument;
doc.open();
doc.write('<!doctype html><html></html>');
// If we call `doc.close()` here it works fine. But google ads doesn't do that.
Henri, Is that a bug or an expected behavior ?
|
||
Comment 4•12 years ago
|
||
Not closing a document like that means it's not done loading yet (in particular, more write() calls will add more content), so yes, not firing onload until close() in that case is correct last I checked.
|
|
||
Comment 5•12 years ago
|
||
(In reply to Alexandre Poirot (:ochameau) from comment #3)
> doc.open();
> doc.write('<!doctype html><html></html>');
> // If we call `doc.close()` here it works fine. But google ads doesn't do
> that.
>
> Henri, Is that a bug or an expected behavior ?
Expected behavior. The doc hasn't finished loading before doc.close() is called.
|
|
Reporter | |
Comment 6•12 years ago
|
||
Ok it looks like waiting for `load` event was a bad choice.
I'll look into nsIWebProgressListener as it seems to be used for url bar throbber to determine when a document is loaded and doesn't suffer from this endless loading state.
Henri, Boris, Thanks for your help!
Status: NEW → RESOLVED
Closed: 12 years ago
Component: DOM: Events → DOM: Device Interfaces
Resolution: --- → INVALID
|
||
Updated•12 years ago
|
Component: DOM: Device Interfaces → DOM: Events
|
||
Updated•12 years ago
|
Component: DOM: Events → DOM
|
Assignee | |
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•