- From: wisniewskit <notifications@github.com>
- Date: Wed, 14 Sep 2016 16:00:34 -0700
- To: whatwg/xhr <xhr@noreply.github.com>
- Message-ID: <whatwg/xhr/issues/72/247182864@github.com>
Having just tested send-response-event-order.htm, send-no-response-event-order.htm, and abort-event-order.htm in Chrome, Firefox, Edge, and a fresh WebKit trunk build, I would recommend these changes: 1. Move "handle response end-of-body" step 10 up so that it is between steps 4 and 5. That is what the browsers are all doing right now: sending their final progress event *before* switching to readyState=4. 2. If it's desired to ensure that progress events' "loaded" values are always greater than (and not equal to) any prior event named progress for the request, then note this in the spec, and change "process response" step 10.4 and "process request body" step 2 to not fire any event if loaded=total (to ensure that we don't potentially repeat sending the "100%" event twice for the upload or download phases). Or if it doesn't matter to the spec whether there are such repeated events, then the tests should be changed so they do not expect only a single event named progress. 3. "process request end-of-body" can remain as-is, since the browsers all fire the progress event as per the spec's current event ordering. 4. Remove the progress events from "handle request error". This is not a decision based on the browser implementations, since there is no consensus among them; Chrome and Edge do not fire them, but WebKit trunk does, and Firefox soon will in version 51, but only because an effort is being made to match the spec right now (see https://bugzilla.mozilla.org/show_bug.cgi?id=918703). As such they might as well just be removed entirely, considering that they don't add any useful information and thus appear to just be wasted effort. 5. Change progress-events-response-data-gzip.htm to remove its check that ProgressEvents will never have loaded=total before readyState=4 (and instead check that the loaded values always increase, if that was the decision that was made in [2]). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/xhr/issues/72#issuecomment-247182864
Received on Wednesday, 14 September 2016 23:01:04 UTC