Bug 151189 - XMLHttpRequest should emit one LOADING state change event.
Summary: XMLHttpRequest should emit one LOADING state change event.
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: XML (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: youenn fablet
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-11-12 05:19 PST by youenn fablet
Modified: 2016-07-18 13:07 PDT (History)
2 users (show)

See Also:


Attachments
Patch (10.30 KB, patch)
2015-11-12 05:22 PST, youenn fablet
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description youenn fablet 2015-11-12 05:19:33 PST
As per the spec, XMLHttpRequest should emit one LOADING state change event.
Currently, it is sending one for each received chunk as a way to keep track of progress.
Now that progress events are available, we can probably safely remove the emition of several LOADING events.

Firefox and Chrome are passing http://www.w3c-test.org/XMLHttpRequest/event-readystatechange-loaded.htm
Comment 1 youenn fablet 2015-11-12 05:22:23 PST
Created attachment 265386 [details]
Patch
Comment 2 Alexey Proskuryakov 2015-11-12 09:49:14 PST
Comment on attachment 265386 [details]
Patch

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

> Source/WebCore/ChangeLog:11
> +        (WebCore::XMLHttpRequest::didReceiveData): Removing emition of LOADING state change event for each receiving chunk.

Do you know when this behavior changed in Chrome and Firefox? Progress events are a relatively new feature, so I suspect that many web pages could still rely on getting state change.
Comment 3 youenn fablet 2015-11-12 10:22:03 PST
(In reply to comment #2)
> Comment on attachment 265386 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=265386&action=review
> 
> > Source/WebCore/ChangeLog:11
> > +        (WebCore::XMLHttpRequest::didReceiveData): Removing emition of LOADING state change event for each receiving chunk.
> 
> Do you know when this behavior changed in Chrome and Firefox? Progress
> events are a relatively new feature, so I suspect that many web pages could
> still rely on getting state change.

I was also surprised to see that test actually passing as it was not beginning of this year. Just looking at blink source code, it seems that LOADING events are still emitted though.

I am not sure why http://www.w3c-test.org/XMLHttpRequest/event-readystatechange-loaded.htm is passing. I will do further investigations.
Comment 4 youenn fablet 2015-11-13 07:00:10 PST
(In reply to comment #3)
> (In reply to comment #2)
> > Comment on attachment 265386 [details]
> > Patch
> > 
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=265386&action=review
> > 
> > > Source/WebCore/ChangeLog:11
> > > +        (WebCore::XMLHttpRequest::didReceiveData): Removing emition of LOADING state change event for each receiving chunk.
> > 
> > Do you know when this behavior changed in Chrome and Firefox? Progress
> > events are a relatively new feature, so I suspect that many web pages could
> > still rely on getting state change.
> 
> I was also surprised to see that test actually passing as it was not
> beginning of this year. Just looking at blink source code, it seems that
> LOADING events are still emitted though.
> 
> I am not sure why
> http://www.w3c-test.org/XMLHttpRequest/event-readystatechange-loaded.htm is
> passing. I will do further investigations.

I confirmed that Chrome and Firefox are emiting several LOADING events for http/tests/xmlhttprequest/interactive-state.html and http/tests/xmlhttprequest/small-chunks-response-text.html. I did not have time to check why http://www.w3c-test.org/XMLHttpRequest/event-readystatechange-loaded.htm is passing though.

I wonder whether we should not mark this test and this bug as WONTFIX, given XHR being freezing/stabilizing.