WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED CONFIGURATION CHANGED
151189
XMLHttpRequest should emit one LOADING state change event.
https://bugs.webkit.org/show_bug.cgi?id=151189
Summary
XMLHttpRequest should emit one LOADING state change event.
youenn fablet
Reported
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
Attachments
Patch
(10.30 KB, patch)
2015-11-12 05:22 PST
,
youenn fablet
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
youenn fablet
Comment 1
2015-11-12 05:22:23 PST
Created
attachment 265386
[details]
Patch
Alexey Proskuryakov
Comment 2
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.
youenn fablet
Comment 3
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.
youenn fablet
Comment 4
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.
Ahmad Saleem
Comment 5
2022-06-28 12:56:30 PDT
Following test case is now moved to WPT (Web Platform Tests) and Safari is passing this:
https://wpt.fyi/results/xhr/event-readystatechange-loaded.any.html?label=master&label=experimental&aligned
Although - Chrome is failing it now and they are tracking it via following bug (not updated in a year) -
https://bugs.chromium.org/p/chromium/issues/detail?id=651750
Just wanted to share updated status.
Ryosuke Niwa
Comment 6
2022-06-29 23:11:30 PDT
Closing as config changed since the test is passing for WebKit / Safari now.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug