Bug 33604 – Implement DOMFrameContentLoaded

• Component: DOM
• Status: REOPENED

[Jaka Jančar]

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.

[Alexey Proskuryakov]

Could you please attach a complete test case?

[Alexey Proskuryakov]

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.

[GaoXiong]

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?

[arno.]

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.
~

[arno.]

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.

[WebKit Review Bot]

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

[WebKit Review Bot]

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

[arno.]

Created attachment 158366 [details]
updated patch; use dumpAsText() instead of dumpAsText(true)

[Adam Barth]

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

[Adam Barth]

Is there a spec for this event?

[Adam Barth]

Wikipedia seems to think that this event is non-standard and implemented by Mozilla and Opera only.

[arno.]

(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

[Adam Barth]

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).

[arno.]

(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.

[arno.]

Created attachment 158458 [details]
testcase. Also visible online at http://renevier.net/misc/webkit_33604/

[Adam Barth]

Can't you just listen for the normal DOMContentLoaded event on the contentDocument?

[Adam Barth]

I guess you don't know when the contentDocument exists...  Makes some amount of sense.

[Alexey Proskuryakov]

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?

[arno.]

(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.

[Alexey Proskuryakov]

I see, it fires if the test is opened from a local file, but not if it's opened from Bugzilla.

[arno.]

Created attachment 163430 [details]
updated patch: remove spurious blank line

[Diego Perini]

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.

[Cesar Rincon]

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.

[Andreas Kling]

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.

[Ahmad Saleem]

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!

[Ryosuke Niwa]

I don't think we'd be adding this event at this point.

[Matt Bierner]

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

[Ryosuke Niwa]

(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?

[Alexey Proskuryakov]

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.

[Anne van Kesteren]

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.