Closed Bug 300992 Opened 19 years ago Closed 14 years ago

onreadystatechange (HTML5/Microsoft extension to DOM document) not supported

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b1

People

(Reporter: cdurl, Assigned: darktrojan)

References

()

Details

(Keywords: dev-doc-complete, html5, Whiteboard: parity-IE)

Attachments

(2 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

function GetFrameObj()
				{
					return(window.frames[MName])
				}
				function Create()
				{	
					if(!IsCreated)
					{
						SelfPageElement = GetSelfPageOCXBody()
						//document.write(GetChildPageOCXBody());
						BufferObj.appendChild(SelfPageElement);
						IsCreated = true;
						//GetFrameObj().document.onreadystatechange = CreateOver;
					}
					
				}
				
				function CreateOver()
				{
					var TmpFrameObj = GetFrameObj()
					alert(TmpFrameObj.document.readyState)
					if (TmpFrameObj.document.readyState=="complete")
					{
						TmpFrameObj.document.forms.postBuffer.innerHTML = GetSelfPageOCXBody();
						TmpFrameObj.ReCallfunction = ReCall;
						TmpFrameObj.Post(PageURL)
					}
				}
function GetSelfPageOCXBody()
				{ 
					var ReturniframeObj = document.createElement("iframe");
					ReturniframeObj.height=100;
					ReturniframeObj.width=100;
					ReturniframeObj.name=MName;
					ReturniframeObj.id=MName;
					ReturniframeObj.frameborder=1;
					ReturniframeObj.onreadystatechange = CreateOver
					ReturniframeObj.src="Buffer.htm";
					return(ReturniframeObj);
					//return(iframeOCXBodyA + MName + iframeOCXBodyB);
				}


Reproducible: Always

Actual Results:  
nothing event create

Expected Results:  
Event is work
I don't know whether readystate and readystatechange is definend by W3C DOM or not.
But next site says that "This event is a Microsoft extension to the W3C DOM". 
http://www.devguru.com/Technologies/xmldom/quickref/document_onreadystatechange_event.html
See also another site for "A Cross-Browser DOM Document Wrapper" on "The
readyState Attribute and onreadystatechange Event".
http://www.webreference.com/programming/javascript/domwrapper/4.html

Does "document.all support" by Mozilla family mean whole IE's event model
support or whole IE's event support?
This is indeed is an extension invented by Microsoft. I'm not sure if Gecko will
support it. Didn't find any previous bugs on this, moving to DOM.
Assignee: nobody → general
Component: JavaScript Console → DOM
Product: Firefox → Core
QA Contact: javascript.console → ian
Summary: window.frames[test].onreadystatechange=function (){} event don't work → onreadystatechange (Microsoft extension to DOM document) not supported
Version: unspecified → Trunk
See also bug 347174.
WADA: The general practice has been that if there's no proper behavior that performs the same function within the DOM specification, that the Mozilla has adopted some MS extensions in the past (e.g. innerHTML). There isn't any event defined that tells when DOMContentLoaded is being to true set in Firefox, which I believe is the equivalent of onreadystatechange event with readystate being set to complete. Whether or not MS's method is appropriate or if there'd need to be a Firefox-only proprietary method is a good question. For scripts that rely on the onreadystatechange handlers (this bug) and document.readystate (bug 347174) to work the same as IE, it might make more sense to have an alternate but similiar method for Firefox so we're not locked into their behavior going forward, unless duplicating their behavior isn't something that will be hard to maintain.

So this bug has merit although it's impossible to say whether or not the behavior will need to be the same as IE or Firefox will need to use alternative methods.

Nevertheless, this bug and bug 347174 point to deficiencies that some web developers (including me) are forced to make hacks to get around, which don't work all that well.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Here's a link to some more onreadystatechange documentation: (http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onreadystatechange.asp)

I've attached a test page with the simple code described in that MSDN page that I slightly modified to be cross-browser test code that displays the following output in IE (note document.readyState is bug 347174):
readystate is loading
readystate is interactive
readystate is complete

The sample code is shown below for your convenience:

if (typeof(document.onreadystatechange) != "undefined")
 document.onreadystatechange=fnStartInit;
function fnStartInit()
{
 if (document.readyState && document.readyState=="interactive")
 {
   document.body.innerHTML += "readystate is interactive<br>\n";
 }
 if (document.readyState && document.readyState=="complete")
 {
   document.body.innerHTML += "readystate is complete<br>\n";
 }

}
if (document.readyState)
 document.writeln("readystate is "+document.readyState+"<br>\n");
Attachment #246803 - Attachment description: readystate test page → onreadystatechange test page
I was a little unclear in comment #4. Here's more clarification on IE's behavior versus Firefox's behavior: 
In IE, If readystate is set to "interactive", the DOM is in the process of being created. Only some elements in the DOM can be accessed. If it's set to "complete", the DOM is fully accessible. In IE, unlike 
In Firefox, the event DOMContentLoaded is called after the DOM is accessible, which has no exact counterpart in IE, since in IE the DOM is only fully accessible after onLoad has been called. The equivalent to onreadystatechange being called with readystate set to "complete" would be the onLoad event. Unfortunately, in Firefox, there also isn't any way to check whether onLoad has already been called, whereas in IE, you can check whether readystate is already set to "complete".

Therefore, a readystate of "interactive" would apply to before the event DOMContentLoaded is called. 
A readystate of "complete" would apply to after the event onLoad is called. Nothing would apply to when the event DOMContentLoaded is called unless we made up some additional state, which would probably wreak havok with IE users.

In that light, it may make more sense to just go by IE's behavior for readystate as much as possible, and then define a read-only property that provides more resolution, such as mozDomContentLoaded and mozPageLoaded or something of that nature.
I've submitted a patch to bug 347174, which is related to this bug.  As I note there, I'm new to the Mozilla code and didn't feel confident doing anything possibly tricky/leaky (like firing an event).  But someone more confident than me could easily build on the work I did there to fire an event when readyState changes.
Assignee: general → nobody
QA Contact: ian → general
This is part of the W3C working draft for XMLHttpRequest now: http://www.w3.org/TR/XMLHttpRequest/#event-handler-attributes

Maybe it should be blocking the HTML5 meta-bug?
XMLHttpRequest has nothing to do with this bug.
(And XMLHttpRequest isn't in HTML5 draft.)

But HTML5 does have onreadystatechange in the Document interface.
http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#documents
Attached patch patch (obsolete) — Splinter Review
Attachment #452682 - Flags: review?(Olli.Pettay)
Could you dispatch the event using a script runner?
Basically, create nsIDOMEvent, then nsPLDOMEvent and use its RunDOMEventWhenSafe method.
Attached patch patch (obsolete) — Splinter Review
(In reply to comment #12)
> Could you dispatch the event using a script runner?
> Basically, create nsIDOMEvent, then nsPLDOMEvent and use its
> RunDOMEventWhenSafe method.

Like this?

I've also changed it to not bubble, which is more consistent with IE.
Assignee: nobody → geoff
Attachment #452682 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #453228 - Flags: review?(Olli.Pettay)
Attachment #452682 - Flags: review?(Olli.Pettay)
Comment on attachment 453228 [details] [diff] [review]
patch

Because of some changes last night, this doesn't apply cleanly to m-c.
Otherwise looks ok to me.
Attached patch patchSplinter Review
This is my first patch since I started using Mercurial queues. Please check I didn't stuff anything up :)
Attachment #453228 - Attachment is obsolete: true
Attachment #453603 - Flags: review?(Olli.Pettay)
Attachment #453228 - Flags: review?(Olli.Pettay)
Attachment #453603 - Flags: review?(Olli.Pettay) → review+
Attachment #453603 - Flags: superreview?(jst)
Attachment #453603 - Flags: superreview?(jst) → superreview+
OS: Windows XP → All
Hardware: x86 → All
Whiteboard: parity-IE
http://hg.mozilla.org/mozilla-central/rev/bdde034a1265
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a6
Flags: in-testsuite+
Keywords: html5
Summary: onreadystatechange (Microsoft extension to DOM document) not supported → onreadystatechange (HTML5/Microsoft extension to DOM document) not supported
So you post that is it fixed and implemented but don't bother to test? It doesn't work. This isn't an AJAX event. This is a DOCUMENT event. It fires when ANYTHING is being loaded.

Let's assume that the PDF file being request below is coming from a server that sets the Content-Disposition header to "attachment" forcing the browser to ask the user to SAVE or VIEW. The script below will HIDE the body of the document until the PDF file is loaded and the browser prompts the user to view or save. Then the document body is made visible. This is the purpose of the onReadyStateChange event.

<html>
<body>

VISIBLE!!!

<script>

function TEST()
{
     if ( document.readyState == 'interactive' )
     {
          document.body.style.visibility = 'visible';
          alert( 'Asking to SAVE or VIEW' );

     }
}

document.onreadystatechange = TEST;
document.body.style.visibility = 'hidden';
self.location.href = 'http://www.nws.noaa.gov/nwr/same.pdf';

</script>

</body>
</html>


So you can UNRESOLVE it and UNFIX is because it doesn't work.

And don't hide behind other people's specs. Use some common sense. Make it actually work, or don't bother to include it. If some ridiculous spec said that no images should load when using HTTPS, would you implement it??? Don't be a follower. Be a leader. This is why IE will always be the leading browsers. They implement features that make sense. They don't rely on idiots to guide them.
(In reply to comment #19)
> document.onreadystatechange = TEST;
> document.body.style.visibility = 'hidden';
> self.location.href = 'http://www.nws.noaa.gov/nwr/same.pdf';

Your code doesn't work because you're setting an event handler on one document and expecting it to work on a different document.

Also, don't rant here, it's a good way to get your account banned.
That's interesting Geoff, because it works just fine in IE. And the link: https://developer.mozilla.org/en/DOM/document.onreadystatechange states that it has been implemented. But it hasn't been implemented properly. Is the objective to LACK functionality and meet some arbitrary, insufficient specification... or provide functionality to meet other browsers?

In the above code, you set the event on the current document and change the location of the window. The current DOCUMENT is never unloaded. Go ahead and set a BODY.ONUNLOAD event or WINDOW or FRAMESET.ONUNLOAD event on the current window/document. If the requested file is a PDF with a disposition of 'ATTACHMENT' the file is not parsed and the UNLOAD events never fire because the document is not unloaded. If the document is not unloaded, then it is the current document object. If it is the current document object then any document-level events associated with it (like onreadystatechange) should fire.

How else can you monitor the readystate of a file being downloaded within the current window while the current document object is currently loaded?
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: