Closed Bug 290127 Opened 15 years ago Closed 13 years ago
Request should be able to register "readystatechange" and "progress" events listeners by add Event Listener() method
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ru-RU; rv:1.7.5) Gecko/20041108 Firefox/1.0 (ax) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; ru-RU; rv:1.7.5) Gecko/20041108 Firefox/1.0 (ax) When I try register "readystatechange" and "progress" events listeners then I get exception : Error: uncaught exception: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMEventTarget.addEventListener]" nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"]. What aim was pursued when nsIOnReadyStateChangeHandler interfaces was used instead of nsIDOMEventListener interface? Therefore it's possible there is no way to register "readystatechange" event listener by addEventListener() methods in current realization. But why is it impossible to register "progress" event listener by addEventListener() method? Reproducible: Always Steps to Reproduce:
Not HTTP networking. Note that an XMLHttpRequest object is just not an EventTarget and it's not clear why it should be one.
Assignee: darin → general
Component: Networking: HTTP → DOM: Mozilla Extensions
QA Contact: networking.http → ian
Why shouldn't it be? Currently the Web Apps spec asserts that it should, because it seemed logical to me to make everything that looked like an event target actually be an event target. I'm happy to update the spec if there are good reasons to not do this, but what are those reasons? Consistency seems good here, and this isn't a case of an arbitrary consistency IMHO.
If it's an eventTarget, then anyone can dispatchEvent on it (and thus spoof progress events, etc). Is that really desirable?
To comment#3. Everyone can dispatch "error" and "load" events. What the difference between "error", "load" events and "progress", "readystatechange" events?
People can already just call the onreadystatechange handler, etc, what's the difference? Don't forget that once someone has access to your execution context, all bets are off anyway. Spoofed events are the least of your problems.
Ian, I suggest that XMLHttpRequest doesn't fit with DOM events if you take a 'tiered' view of event handling facilities, from a Web developer's perspective: tier 1: DOM 0 / DOM 1 HTML event handler support tier 2: DOM 2/3 Events handler support tier 3: ECMAScript page-visible Host object services. tier 4: ECMAScript chrome-visible Host object services. "Clearly" XMLHttpRequest isn't in the same class as tiers 1/2. The problem is that many sophisticated event handling models are presented by advanced Host objects in chrome. For example content sink registration. The line has to be drawn somewhere between exposed application event processing and document event handling. To bolt on addEventListener is to begin grafting DOM 3 Event semantics onto the UA's internals. Restrictive and perhaps not appropriate. A UA isn't a document. I agree that the Windows-centric event model that currently exists for XMLHttpRequest is less than ideal; but there's no overarching cross-browser framework currently. You would first have to persuade somebody (everybody) that the HTML element deserved "progress" events in addition to "load"/"unload", and that that such events were not DOM 3 Events but rather something else. Then that could also be applied to XMLHttpRequest, RDF, LoadGroups, whatever. Alexander, you make a good case based on the fringe-dwelling error/load events. A UA is still not a document, though. I suggest to you that an "onreadystatechange" handler is effectively a "XMLHttpRequest level 0 handler". Any better solution (as DOM 1 is to DOM 0) requires the backing of a proper object model standard, even if you're right. I don't see a section in the WHATWG docs on "content processing events". Furthermore, such a section probably should not mindlessly copy MS Window semantics, as the current level 0 features do. - N.
I don't understand what you are trying to say. As far as I can see the UA internals are irrelevant here. If something looks like an event handler (and "onreadystatechange" sure does) then it should act like one, and part of being an event handler is being an EventTarget, with all that that implies. But if you disagree please raise the issue on the WHATWG list.
"If it looks like an event handler it should be one" "UA internals are irrelevant" This is precisely wrong, and since this isn't a WHATWG bug, I'll argue why here. The central point is that both loaded documents and UAs are made up of objects. XMLHttpRequest is an example of a UA object being wrapped & exposed into the document object model. The UA has a different set of object semantics to the DOM, and that includes different semantics for internal "handlers", which in the UA are called commands, sinks, observers, signal handlers, and so on. Exposing UA objects to ordinary DOM scripts, where DOM semantics are de rigeur reveals these differences and hence prompts this bug. The "bug" really is that this UA object was hastily exposed, and now requires semantic analysis and de jure standardisation, not that this poorly envisioned object needs to be retro-fitted to the DOM. If you try to force the XMLHt... square peg into the round hole that is DOM 3 Events, you might shoehorn it in with effort, but as more facilities of the UA are exposed to the document scripting environment (eg RDF, forthcoming), you will inevitably start failing, because those facilities are increasingly divergent from DOM. Better to take a step back and formalise HOW desireable UA facilities and their semantics could be seperately imported into document scripting context, just as the DOM semantics have been. I'm not against standardisation in this case, but treating XMLHttp...like a nail just because you have a hammer is a primitive approach. In order to get this bug WONTFIXed, I suggested "content processing events" as a more general forward strategy that would accomodate the UA sematics associated with content listeners like XMLHttpRequest handlers. Once standardised, that would spawn a different DOM enhancement request, though. Happy to discuss such things via email. - N.
That all sounds very reasonable, until you actually look at the XMLHttpRequest object, and notice that it could quite sanely be an EventTarget as well. I really don't see the problem here. This really has very little to do with the DOM.
Perhaps you could suggest how bubbling/capture works for such a DOM event, given that the XMLHttpRequest object isn't in any DOM Document. Or are you suggesting it be half a DOM event, with addEventListener but no propogation? That yields not one but two different sets of event semantics, which is hardly a simplification. In fact it's a point of confusion since the two would be superficially similar. It's not just a matter of API, there's processing considerations. More generally, Longhorn's split between Indigo/Avalon/Winfs = network/screen/disk is a powerful and simple high level architecture, and one that UAs object models can easily be informed by; UAs can also be informed by Java object models. XMLHttpRequest more properly attaches to Necko than Gecko, and if browsers are to start sporting network services (SOAP, WSDL, XML-RPC, etc) then that is clearly a problem space seperate to the problem space of documents - a problem space that should have its own semantic model. In the big picture I agree all this should be made simpler for web developers, but simpler via a more complete plan. WHATWG Communication Services? - N.
Maybe is it better to invert this bug? If it is more right to remove DOM events from XMLHttpRequest object then let remove 'load' and 'error' events as DOM events.
load/unload are part of HTML 4.01 and load/unload/error are part of DOM 2 Events, so update the standards first if you want them removed. If an XMLHttpRequest object instansiated a .document property before any content loaded, AND if Hixie defined a new WHATWG DOM 3 Events event module "Content" or "Load" or "ContentLoad" or similar, in which "progress" events and friends reside, then web developers could have: var port = new XMLHttpRequest(...); port.document.addEventListener("progress", ...); Furthermore, load/unload/error could be moved to this Content module if everyone could tolerate them supporting the document container (<HTML>, XML container or nothing in the case of plain text or images) as well as the HTML/XHTML BODY/body element. That factors the HTMLEvent module into "strictly HTML" and "any document type". However, that enhancement still wouldn't give support for port.addEventListener("progress", ...); which is this bug. Some trickery could add the non-standard Microsoft events on top of an implemented ContentEvent module for backwards- compatibility, but web developers would have to remember to write: port.onreadystatechange = ... // legacy syntax, supported or port.document.addEventListener("progress", ...); // new standard but not port.addEventListener("progress", ...); // "no property addEventListener". This bug could morph into that alternate enhancement, assuming all those hurdles were jumped AND the other benefit is that no Microsoft IE 4.0 legacy semantics (XMLHttpRequest events) would need to be canonised in standards. Instead, new and properly chosen document events are canonised. - N.
There's no reason why events fired on XMLHttpRequest need to act any differently than those fired on, say, Window. Or Document. Those are just single nodes with no particular propagation or bubbling model. I really don't understand the problem here. There's nothing about DOM Events that makes them inappropriate for anything but trees. Sure, there are features in DOM Events that make them especially appropriate for trees, but that doesn't preclude other objects implementing EventTarget.
Ian, it's just about which model is preferred. Comments 10 and 12 provide more systematic support for content events, support that could apply to all document loading, including the window.document object, images, frames, chrome, everything. Your model is a finger in the dyke, simpler but also less rich and less orthogonal, and it doesn't anticipate network-semantic objects being added to browsers. It burdens the XMLHttpRequest object with DOM semantics in a short-sighted way. Also, hackers may object to treating network objects as document objects, especially in an increasingly network-centric world. I'm not saying that XMLHttpRequest will never get proper events. I'm just saying it should never get DOM events. Please don't feign noncomprehension here again; you know what I mean. Go to email. Cc'ing an AJAXian in case this bug's of brief curiousity value. - N.
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
Who is actually in charge of making this decision? It sounds like a good idea to me, but I think the DOM folks should get their heads together and make a decision.
The reason XMLHttpRequest works like it does now is quite simple - that is how Microsoft did it, and the xml group implemented it so it was compatible with the MS syntax. While I don't see a reason not to implement it, I also don't really see a benefit of implementing it. Could we just map addEventListener("load") to whatever .onload= does easily? If it is too much work, I don't really see the benefit (other than saying we offer a standard-compliant way). If people want loading with DOM events, there is document.load :)
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
I'd do this after Bug 363067. Then XHR could inherit nsPIDOMEventTarget and normal event dispatching would just work.
Adding to CC.
This bug as filed got fixed by the checkin for bug 198595.
Status: NEW → RESOLVED
Closed: 13 years ago
Depends on: 198595
Resolution: --- → FIXED
Need tests, though.
You need to log in before you can comment on or make changes to this bug.