346670 - DOMContentLoaded is not being fired for Javascript-created pages

Status: UNCONFIRMED

Description

[B D]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.5) Gecko/20060719 Firefox/1.5.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.5) Gecko/20060719 Firefox/1.5.0.5

A DOMContentLoaded event anomaly began occurring beginning with the release of Firefox 1.5. When a new html page is created using Javascript (open, write, etc., functions), such as with a bookmarklet, the DOMContentLoaded event is not being fired for those pages. As a specific example, this is causing the Greasemonkey extension to not load/inject scripts for that created page. (this is occurring for pages loaded into a new tab, I haven't checked for pages loaded into a new window, to see if that is different) (as an odd anomaly, these new pages have the same URL address as the parent window/tab, which is odd -- I believe they used to be some sort of a wysiwyg:// scheme URL -- I don't know if this is related to this problem, or not) NOTE also, that if the page is RELOADED using the browser button, or programatically, the DOMContentLoaded event then fires like it should have originally.

Reproducible: Always

Steps to Reproduce:
1. I specifically noticed this occuring while using the Greasemonkey extension, which relies on the DOMContentLoaded event. However, executing any bookmarklet Javascript code (or, I believe, any JS code in a page itself) that opens a new page using open(), write(), etc., will cause this bug. That is, DOMContentLoaded will not fire for that tab/window/page.

Actual Results:  
In the case of the Greasemonkey extension, scripts are not loaded/injected for these pages, which basically causes Greasemonkey to effectively "fail".

Expected Results:  
The DOMContentLoaded event should fire for all pages when they are loaded into tabs and windows, whether those pages are created using Javascript code, or html links to URL's, manually entered addresses, etc.

I don't know if any other information is pertinent to this bug, but I can provide any needed. As far as I know, it is occurring for everyone who is using the Greasemonkey extension on all operating systems. It is pretty easy to test for whether it is occurring, or not.

Comment 1

[Anne-Sofie Nielsen]

Created attachment 251918 [details]
Example of the behavior in Firefox

This HTML page demonstrates the bug as it may be experienced in Firefox.
Here, it is quite annoying that the DOMContentLoaded event is not executed when document.writing the document content.

To reproduce:
1) Open the page in Firefox
2) Click the "Write document" button
3) Observe that the document is written, but no alert shows (as the DOMContentLoaded event is not fired)
4) Observe that if you press the Refresh button, an alert saying "DOM loaded" appears (as the DOMContentLoaded is indeed fired in this case).

Comment 2

[Olli Pettay [:smaug]]

I do see the alert when testing using trunk builds.

Comment 3

[B D]

This is still broken for Firefox 2.0. If the trunk builds work, then maybe the next version will fix it.

Comment 4

[Sunil]

Created attachment 716312 [details]
Creates nested iframes using Javascript

Comment 5

[Sunil]

I am seeing the same problem on Firefox 18 and 19. The attached file 'Creates nested iframes using Javascript' creates iframes using Javascript and none of the event fires. 

Chrome fires all the events diligently. 

The same issue is there if the iframe was created using Data URI.

Comment 6

[Boris Zbarsky [:bzbarsky, bz on IRC]]

That testcase has nothing to do with this bug, since it doesn't involve DOMContentLoaded in any way.

Comment 7

[Sunil]

My bad. I assumed the core issue to be the same that events are not getting fired in general. 

I have created another bug (# 843459) as my test case is related to onload.

Comment 8

[Firefox Product Integrity Bug Husbandry Bot (contact :emceeaich)]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.