Closed Bug 290127 Opened 19 years ago Closed 17 years ago

XMLHttpRequest should be able to register "readystatechange" and "progress" events listeners by addEventListener() method

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: surkov, Unassigned)

References

(
URL
)

Details

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/

still actual
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 :)
Flags: blocking-aviary1.0.7?
Flags: blocking-aviary1.0.7?
URL: http://www.w3.org/TR/XMLHttpRequest/#...
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.
Depends on: 363067
Adding to CC.
This bug as filed got fixed by the checkin for bug 198595.
Status: NEW → RESOLVED
Closed: 17 years ago
Depends on: 198595
Resolution: --- → FIXED
Need tests, though.
Flags: in-testsuite?
Component: DOM: Mozilla Extensions → DOM
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.