Bug 46743

Summary: Event dispatching in XMLHttpRequestProgressEventThrottle should go through XMLHttpRequestProgressEventThrottle::dispatchEvent
Product: WebKit Reporter: Anton D'Auria <adauria>
Component: WebKit Misc.Assignee: Anton D'Auria <adauria>
Status: RESOLVED FIXED    
Severity: Normal CC: allan.jensen, ap, darin, ddkilzer, eric.carlson, eric, jchaffraix, joepeck, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: OS X 10.5   
Bug Depends on:    
Bug Blocks: 81506    
Attachments:
Description Flags
[PATCH] Refactor XMLHttpRequestProgressEventThrottle event dispatching
none
[PATCH] Refactor XMLHttpRequestProgressEventThrottle event dispatching (with ChangeLog)
none
Patch
jchaffraix: review+, jchaffraix: commit-queue-
Patch for landing none

Description Anton D'Auria 2010-09-28 11:57:17 PDT
In XMLHttpRequestProgressEventThrottle, we should dispatch events through XMLHttpRequestProgressEventThrottle::dispatchEvents, instead of calling m_target->dispatchEvent in various places. This makes it easy to add multiple event queuing (currently, one progress event can be queued on suspend(), if progress events have been throttled).
Comment 1 Anton D'Auria 2010-09-28 12:03:38 PDT
Created attachment 69081 [details]
[PATCH] Refactor XMLHttpRequestProgressEventThrottle event dispatching

In preparation for platform-specific queuing of XMLHttpRequest events, this patch changes all calls to m_target->dispatchEvent to XMLHttpRequestProgressEventThrottle::dispatchEvent. Currently, we queue up only a progress event on suspend() if we have throttled progress events. We should be able to queue all XHR events that  can be generated after suspend(), if the platform network layer continues to receive data. XMLHttpRequest uses XMLHttpRequestProgressEventThrottle to dispatch only download events, so this doesn't change behavior of upload events, which aren't throttled or queued.
Comment 2 Anton D'Auria 2010-09-28 12:41:19 PDT
Created attachment 69088 [details]
[PATCH] Refactor XMLHttpRequestProgressEventThrottle event dispatching (with ChangeLog)

Added ChangeLog
Comment 3 Alexey Proskuryakov 2010-09-28 19:49:05 PDT
I still question the need to queue multiple events in XMLHttpRequest.
Comment 4 Alexey Proskuryakov 2010-09-30 08:55:30 PDT
This makes control flow a little confusing. If XMLHttpRequestProgressEventThrottle::dispatchEvent() is called with FlushProgressEvent action, it will call flushProgressEvent(), which will now call XMLHttpRequestProgressEventThrottle::dispatchEvent() back recursively.
Comment 5 Darin Adler 2010-10-13 17:09:16 PDT
Comment on attachment 69088 [details]
[PATCH] Refactor XMLHttpRequestProgressEventThrottle event dispatching (with ChangeLog)

I do not like the ProgressEventAction design here. It seems if we want to do two things we should call two functions, or we can have a function that does two things, but having function with a passed parameter that tells it to either do two things or one thing seems unnecessarily confusing.
Comment 6 Darin Adler 2010-10-13 17:09:51 PDT
(In reply to comment #4)
> This makes control flow a little confusing. If XMLHttpRequestProgressEventThrottle::dispatchEvent() is called with FlushProgressEvent action, it will call flushProgressEvent(), which will now call XMLHttpRequestProgressEventThrottle::dispatchEvent() back recursively.

I agree that it makes the control flow confusing. Despite that, I said review+. My ProgressEventAction comment might help, though.
Comment 7 Darin Adler 2010-10-13 17:10:15 PDT
Alexey, if you had said review- I would not have done a review+. I didn’t notice your comments until afterward.
Comment 8 Alexey Proskuryakov 2010-10-13 17:17:49 PDT
Comment on attachment 69088 [details]
[PATCH] Refactor XMLHttpRequestProgressEventThrottle event dispatching (with ChangeLog)

My understanding is that Anton wanted to look into whether the change was needed for his project again, so I'll set cq- for now. Please feel free to flip it back if necessary.
Comment 9 Eric Seidel (no email) 2010-12-14 15:14:52 PST
Ping?  Should this bug be closed or is this still for landing?
Comment 10 Eric Seidel (no email) 2010-12-20 22:59:17 PST
Looks like this was never landed.  I expect the patch has rotten by now.
Comment 11 Allan Sandfeld Jensen 2012-03-21 12:17:19 PDT
Created attachment 133091 [details]
Patch
Comment 12 Julien Chaffraix 2012-03-22 07:39:06 PDT
Comment on attachment 133091 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=133091&action=review

> Source/WebCore/ChangeLog:8
> +

Please add some details about your change and most importantly *why* you are doing it (as a stepping stone to implement event queuing in XMLHttpRequestProgressEventThrottle). The original ChangeLog had a very nice description:

In preparation for platform-specific queuing of XMLHttpRequest events,
this patch changes all calls to m_target->dispatchEvent to
XMLHttpRequestProgressEventThrottle::dispatchEvent. Currently,
we queue up only a progress event on suspend() if we have throttled
progress events. We should be able to queue all XHR events that
can be generated after suspend(), if the platform network layer continues
to receive data. XMLHttpRequest uses XMLHttpRequestProgressEventThrottle
to dispatch only download events, so this doesn't change behavior of upload
events, which aren't throttled or queued.
Comment 13 Allan Sandfeld Jensen 2012-03-22 08:06:04 PDT
Created attachment 133265 [details]
Patch for landing
Comment 14 WebKit Review Bot 2012-03-22 10:02:03 PDT
Comment on attachment 133265 [details]
Patch for landing

Clearing flags on attachment: 133265

Committed r111717: <http://trac.webkit.org/changeset/111717>
Comment 15 WebKit Review Bot 2012-03-22 10:02:08 PDT
All reviewed patches have been landed.  Closing bug.