Bug 33604 - Implement DOMFrameContentLoaded
Summary: Implement DOMFrameContentLoaded
Status: REOPENED
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: 2023-08-23 07:47 PDT (History)
19 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.
Comment 25 Ahmad Saleem 2022-08-10 16:30:48 PDT
I am not getting clear behaviour of DOMFrameContentLoaded from the above test cases, so I took one from Mozilla Bugzila:

Link - https://bug431833.bmoattachments.org/attachment.cgi?id=319075

It shows "FAIL" for Safari 15.6 and Chrome Canary 106 and it does 'PASS' for three frames in Firefox Nightly 105.

I was not available to find any MDN link and any update on Google about whether there is any plan to make spec around it or not except one link same as Comment 12.

Although there is a bug on Mozilla Bugzilla to remove this but with no activity - https://bugzilla.mozilla.org/show_bug.cgi?id=1537766

Are we considering to spec it or we should mark this as "RESOLVED WONTFIX"? Appreciate if some can update this or mark this bug accordingly. Thanks!
Comment 26 Ryosuke Niwa 2022-08-13 22:30:46 PDT
I don't think we'd be adding this event at this point.
Comment 27 Matt Bierner 2022-08-17 15:01:41 PDT
Are there any good workarounds if this won't be fixed?

For VS Code, we need to know when a sandboxed iframe (which may have scripts disabled) is ready. On Firefox and Chromium, we simply listen to `DOMContentLoaded` on the iframe but for Safari we had to resort to polling the iframe's location and readyState
Comment 28 Ryosuke Niwa 2022-08-17 22:26:29 PDT
(In reply to Matt Bierner from comment #27)
> Are there any good workarounds if this won't be fixed?
> 
> For VS Code, we need to know when a sandboxed iframe (which may have scripts
> disabled) is ready. On Firefox and Chromium, we simply listen to
> `DOMContentLoaded` on the iframe but for Safari we had to resort to polling
> the iframe's location and readyState

Are you saying that DOMContentLoaded gets fired in Blink? Do you have any test case demonstrating the difference?
Comment 29 Alexey Proskuryakov 2022-08-24 10:24:27 PDT
A DOMContentLoaded event listener set on iframe.contentWindow works in all browsers on simple test cases, but

- It doesn't work for cross-origin frames, of course.
- WebKit has bug 215589, which breaks sandboxed frames.
- The fact that we are setting the listener on a window object that can be replaced by navigation makes me suspect that there are other cases where it "works" in some browsers but not in others, making it look like a WebKit limitation.

There doesn't seem to be any reasonable way to achieve what DOMFrameContentLoaded does in the general case.

This bug has transformed somewhat over time, but most of the discussion is about why DOMFrameContentLoaded is needed, so I'm going to reopen, and to retitle for clarity.
Comment 30 Anne van Kesteren 2023-08-23 07:47:25 PDT
It seems to me we should address these two cases

- WebKit has bug 215589, which breaks sandboxed frames.
- The fact that we are setting the listener on a window object that can be replaced by navigation makes me suspect that there are other cases where it "works" in some browsers but not in others, making it look like a WebKit limitation.

and not add a new non-standard event with hard-to-nail-down timing.