Closed Bug 312213 Opened 19 years ago Closed 18 years ago

No way to track progress in send for XMLHttpRequest

Categories

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

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: readams, Assigned: readams)

References

Details

(Keywords: dev-doc-complete)

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051010 Firefox/1.0.7 (Ubuntu package 1.0.7)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051010 Firefox/1.0.7 (Ubuntu package 1.0.7)

Currently, XMLHttpRequest eats progress notifications during the send phase
because to construct an event, it needs a document, but the document isn't
initialized until later.

I considered simply "fixing" this, but there's probably code out there that
relies on getting progress notifications only while receiving.  So the attached
patch will send progress notifications during the send phase to an
"onuploadprogress" handler registered at the same time an onprogress handler is
registered.

Reproducible: Always
Attachment #199322 - Flags: review?(jst)
How does IE's XMLHttpRequest handle this situation?
I don't believe IE offers progress notifications of any kind.  Only state change
notifications through the onreadystatechange handler.
Comment on attachment 199460 [details] [diff] [review]
New version fixes capitalization style on InitDocument, and fixes the reversed senses of onprogress and onuploadprogress.  (oops)

ping?
Assignee: xml → general
Status: UNCONFIRMED → NEW
Component: XML → DOM: Mozilla Extensions
Ever confirmed: true
QA Contact: ashshbhatt → ian
nsIXMLHttpRequest.idl needs a new IID...
Note that my patch in bug 198595 has a very similar setup, though it would just always send progress notifications (for both save and receive).  Note sure which is more desirable.  sicking, what do you think?

That said, once bug 324865 is fixed it'll be possible to create events in a much less cumbersome fashion, without the need for a document.
Depends on: 198595
Attachment #199322 - Flags: review?(jst)
Comment on attachment 199460 [details] [diff] [review]
New version fixes capitalization style on InitDocument, and fixes the reversed senses of onprogress and onuploadprogress.  (oops)

This looks fairly reasonable, but it would need to be merged to trunk.  It also suffers from bug 334368, so we'd want either that or bug 324865 fixed before this lands.
Attachment #199460 - Flags: review?(jst) → review-
Rob, I'm sorry it took so long to get that patch looked at.  We're usually better about that sort of thing.  :(
I think we should have separate handlers for upload and download progress notifications. I'm not convinced we need a new onX method, but rather letting users call addEventListener("uploadprogress") or some such.
OK, can do.

Rob, would you mind me rolling your changes into the patch on bug 198595 (with credit to you of course)?  Otherwise that patch will cause issues, as you noted...
If the intend of comment 10 is to create new events in the null namespace I suggest to take that up with public-webapi.
That is the intent; I've sent mail to the webapi WG.
Assignee: general → readams
Fixed on trunk by checkin for bug 198595, which needed to include these changes to be correct.  Rob, thanks for the patch!
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Rob, we're likely to change how upload progress events work -- see the public-webapi@w3.org archives.  Would that break something for you in an irreperable way, or can you adjust your code to deal with it?
I gather from the comments here that this hasn't fully settled yet?
You can go ahead and change it; it won't hurt me.
> I gather from the comments here that this hasn't fully settled yet?

Indeed.  We thought it had, but the webapi WG had other ideas.  ;)
If this is still in the process of making its way through the WG, should we undo the "fixed" status on this, or is it still considered fixed even though it may be changing?

I'm just trying to keep track of when I need to document this. :)
http://dev.w3.org/2006/webapi/XMLHttpRequest-2/Overview.html has a proposal on when to dispatch the progress events. The progress events themselves are defined in http://www.w3.org/TR/progress-events/ in an attempt to have the interfaces and semantics shared between specifications. (HTML5 <video> is using them too iirc.)

At this point implementation experience is probably needed to fill in the remaining details.
Unfortunately we're after feature freeze so it's sort of too late to implement the webapi proposal.

Does the current implementation in firefox make it harder to in a later release implement things the spec-compliant way? If so that would be a good argument for accepting a new patch.
This bug is fixed.  We should file a followup bug on implementing the (much later) W3C proposal.

I would probably hold off on documenting this until closer to release when it's clear what our story is.

As for compat between what we do and what the spec says, for "onprogress" and the "progress" event we're compatible in terms of XMLHttpRequest.  For upload progress (what this bug is about), our current implementation in no way precludes implementing the W3C thing, as far as I can tell.

One other issue is that the actual event object we dispatch is fundamentally different from the one specified in http://www.w3.org/TR/progress-events/ (which agains significantly post-dates our implementation).  We dispatch the existing-standard LSProgressEvent, whereas the new progress event interface has a different name, completely different members, etc.  We could probably implement both interfaces on XMLHttpProgressEvent, since the members are completely different.

So I do think that we can do the W3C spec alongside what we implement.  And we can't easily ditch what we implement anyway, since content might be depending on it.  It would be nice to get the W3C stuff into 1.9, but I think sicking is right that it's just coming too late in the cycle.
Boris: Did we have the LSProgressEvent implemented in Firefox 2 too? If not I wonder if it would be worth just fixing the event object to follow w3c since otherwise I bet over time everyone would have to implement all properties from both interfaces.
For download progress, our progress event implementation dates back to Gecko 1.8, with a backport to the Aviary branch (though that's not obvious, because dates on revisions get blown away when a file gets CVS moved).  See bug 251418.  So we've had it in place since Firefox 1.0.
Oh, wow, ok, that's not going anywhere any time soon then :(
OK, then I'm going to plan not to document this for the time being, and will revisit it at a later time.
Do we have any tests for this?
Not yet...
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.

Attachment

General

Creator:
Created:
Updated:
Size: