Bug 33604 - iframe.contentWindow doesn't fire DOMContentLoaded (implement DOMFrameContentLoaded?)
Summary: iframe.contentWindow doesn't fire DOMContentLoaded (implement DOMFrameContent...
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: Other Other
: P2 Normal
Assignee: arno.
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-13 09:15 PST by Jaka Jančar
Modified: 2020-08-18 09:57 PDT (History)
15 users (show)

See Also:


Attachments
patch proposal (7.44 KB, patch)
2012-08-13 17:10 PDT, arno.
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from gce-cr-linux-01 (398.70 KB, application/zip)
2012-08-13 18:41 PDT, WebKit Review Bot
no flags Details
updated patch; use dumpAsText() instead of dumpAsText(true) (7.99 KB, patch)
2012-08-14 10:43 PDT, arno.
no flags Details | Formatted Diff | Diff
testcase. Also visible online at http://renevier.net/misc/webkit_33604/ (17.23 KB, application/zip)
2012-08-14 17:45 PDT, arno.
no flags Details
original example as test case (302 bytes, text/html)
2012-08-15 09:36 PDT, Alexey Proskuryakov
no flags Details
updated patch: remove spurious blank line (7.83 KB, patch)
2012-09-11 14:01 PDT, arno.
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jaka Jančar 2010-01-13 09:15:36 PST
I'm trying to do the following from a locally saved (so it isn't limited by SOP) webpage:

    iframe.contentWindow.addEventListener('DOMContentLoaded', function() {
        alert('contentWindow DOMContentLoaded: '+iframe.contentDocument.title);
    });


I can navigate iframe.contentWindow and iframe.contentDocument OK, but this event will never fire.
Comment 1 Alexey Proskuryakov 2010-01-14 15:58:57 PST
Could you please attach a complete test case?
Comment 2 Alexey Proskuryakov 2010-03-06 17:07:40 PST
Also, Mozilla documentation says that there is a different event that is supposed to work for subframes, see DOMFrameContentLoaded in <https://developer.mozilla.org/en/Gecko-Specific_DOM_Events>. But we don't implement that anyway.
Comment 3 GaoXiong 2011-10-11 04:01:28 PDT
It seems that this usage like iframe.contentDocument.addEventListener is NOT reasonable.

Because the listener function is on the level of this frame's parent, but the event target is inside the frame level, these two levels can not communicate with each other.

Could some one please tell me whether I got the correct understanding?
Comment 4 arno. 2012-08-13 16:55:51 PDT
Currently, there is no way to known when a frame dom has finished loaded.
We could try to add a DOMContentLoaded listener to the iframe contentDocument.
But when frame has just been created, contentDocument is an about:blank document.

<iframe src="iframe.html"></iframe>
<script>
var iframe = document.getElementById('iframe');
var doc = iframe.contentDocument; // about:blank document
</script>

When we try to access contentDocument later, document may (or may not) have
been replaced by loaded document, and we have no way on nothing when it will be
replaced.

By searching on google, I discovered that some people call setTimeout
repetitively until document.readyState is loaded or complete. The alternative
is to use load event, but if there are a lot of external resources, there may
be some delay between the document readyness, and the load event.

So, it may be nice to have DOMFrameContentLoaded event, which is already
implemented in Firefox and in Opera.
~
Comment 5 arno. 2012-08-13 17:10:53 PDT
Created attachment 158148 [details]
patch proposal

Currently, Firefox and Opera both implement DOMFrameContentLoaded events.

When a frame has been loaded, opera dispatches an event on the owner iframe. This event then bubbles up to the window.

Firefox dispatch an event on the document on the owner iframe. It bubbles to the window. target of that element is the iframe whose content has loaded. If the owner document is itself contained in a frame, a event is dispatched to the parent document. event target is still the frame when content has loaded (and so on to the top of the parent document chain)

In this patch, I implement opera's behaviour, first because it was the simplest way, and also because I don't really see advantage of ascending the event two or more frames upper. But I can try to implement firefox's behaviour if that's useful.
Comment 6 WebKit Review Bot 2012-08-13 18:41:24 PDT
Comment on attachment 158148 [details]
patch proposal

Attachment 158148 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/13484984

New failing tests:
http/tests/misc/DOMFrameContentLoaded-event.html
Comment 7 WebKit Review Bot 2012-08-13 18:41:28 PDT
Created attachment 158182 [details]
Archive of layout-test-results from gce-cr-linux-01

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: gce-cr-linux-01  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.39-gcg-201203291735-x86_64-with-Ubuntu-10.04-lucid
Comment 8 arno. 2012-08-14 10:43:14 PDT
Created attachment 158366 [details]
updated patch; use dumpAsText() instead of dumpAsText(true)
Comment 9 Adam Barth 2012-08-14 13:30:19 PDT
Comment on attachment 158366 [details]
updated patch; use dumpAsText() instead of dumpAsText(true)

View in context: https://bugs.webkit.org/attachment.cgi?id=158366&action=review

> Source/WebCore/dom/Document.cpp:4871
> +

This change seems spurious
Comment 10 Adam Barth 2012-08-14 13:31:18 PDT
Is there a spec for this event?
Comment 11 Adam Barth 2012-08-14 13:32:19 PDT
Wikipedia seems to think that this event is non-standard and implemented by Mozilla and Opera only.
Comment 12 arno. 2012-08-14 15:02:34 PDT
(In reply to comment #10)
> Is there a spec for this event?

No, there is no spec for that.
(see end of this message)
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jul/0049.html
Comment 13 Adam Barth 2012-08-14 15:08:25 PDT
You're in a classic chicken-and-egg game.  There are typically two ways to break through:

1) Find content in the world that we'd render better if we implemented this Firefoxism (the legacy path).
2) Explain the use cases that implementing this feature unlocks that are previously difficult to accomplish in the web platform (the new hotness path).
Comment 14 arno. 2012-08-14 17:44:37 PDT
(In reply to comment #13)
> You're in a classic chicken-and-egg game.  There are typically two ways to break through:
> 
> 1) Find content in the world that we'd render better if we implemented this Firefoxism (the legacy path).

Is it's not implemented in webkit nor ie, it's probably not used widely in the web.

> 2) Explain the use cases that implementing this feature unlocks that are previously difficult to accomplish in the web platform (the new hotness path).

This event would allow accessing the content dom of an iframe (or frame) earlier. Currently, the only way to be sure the dom is loaded is to wait for the frame load event. So if the document has lot of external resources, which take a long time to load, there may be a big delay between the moment the dom is ready, and the moment we can access it in webkit.
I'll attach a testcase, it loads an iframe which has an image which takes a long time to load. On browsers which support DOMFrameContentLoaded, we are able to access the frame faster.
Comment 15 arno. 2012-08-14 17:45:23 PDT
Created attachment 158458 [details]
testcase. Also visible online at http://renevier.net/misc/webkit_33604/
Comment 16 Adam Barth 2012-08-14 22:35:49 PDT
Can't you just listen for the normal DOMContentLoaded event on the contentDocument?
Comment 17 Adam Barth 2012-08-14 22:36:11 PDT
I guess you don't know when the contentDocument exists...  Makes some amount of sense.
Comment 18 Alexey Proskuryakov 2012-08-15 09:36:28 PDT
Created attachment 158581 [details]
original example as test case

This is the original example from bug report, attached. DOMContentLoaded does fire in Safari 6 for me.

What's the difference between this test and the more complex one attached above?

On this test case, DOMContentLoaded also fires in Firefox. What's the actual difference between DOMContentLoaded and DOMFrameContentLoaded in Firefox implementation, if any?
Comment 19 arno. 2012-08-15 09:49:52 PDT
(In reply to comment #18)
> Created an attachment (id=158581) [details]
> original example as test case
> 
> This is the original example from bug report, attached. DOMContentLoaded does fire in Safari 6 for me.

It doesn't fire for me in Safari (In reply to comment #18)
> Created an attachment (id=158581) [details]
> original example as test case
> 
> This is the original example from bug report, attached. DOMContentLoaded does fire in Safari 6 for me.

It doesn't for me, neither in Safari 5, in linux chromium nor in trunk GtkLauncher. When the browser first tries to access the iframe (iframe.contentWindow.addEventListener), the iframe contains an about:blank document.
Comment 20 Alexey Proskuryakov 2012-08-15 10:50:14 PDT
I see, it fires if the test is opened from a local file, but not if it's opened from Bugzilla.
Comment 21 arno. 2012-09-11 14:01:13 PDT
Created attachment 163430 [details]
updated patch: remove spurious blank line
Comment 22 Diego Perini 2013-04-30 05:58:26 PDT
The DOMFrameContentLoaded event is really useful when working with iframes.

Frequently it is necessary to start manipulating the DOM as soon as possible, when DOMContentLoaded is fired in the iframe, rather than waiting for a long page and related assets/resources to be completely loaded.

Please implement DOMFrameContentLoaded in Webkit.
Comment 23 Cesar Rincon 2013-09-05 00:30:52 PDT
I also just hit a dead end while trying to implement a content script what must work on a website with frames - e.g. where I don't control the site content myself, so I can't just add javascript to the documents shown in the frames, to listen for DOMContentLoaded there.

It may be a Firefoxism, but an event for DOM readiness that one can listen from the parent frame is the only clean way to implement a class of scripts - those that must work on big documents inside a frame. As long as Webkit doesn't support this, people will write these scripts in a way that either (a) feels more responsive on Firefox, or (b) resort to horrible kludges like polling the frames in a loop or whatnot, which will degrade performance anyway.

Please consider implementing DOMFrameContentLoaded or equivalent.
Comment 24 Andreas Kling 2014-02-05 10:56:20 PST
Comment on attachment 163430 [details]
updated patch: remove spurious blank line

Clearing review flag on patches from before 2014. If this patch is still relevant, please reset the r? flag.