Intent to remove: XMLHttpRequestProgressEvent

[Sigbjorn Finne‏]

Primary eng (and PM) emails

sigb...@opera.com

Link to “Intent to Deprecate” thread
None - asking to go straight for removal.

Summary

Remove support for the XMLHttpRequestProgressEvent interface and have
XMLHttpRequest dispatch ProgressEvent events when reporting progress on
both up&downloads.

XMLHttpRequestProgressEvent is a ProgressEvent-derived interface which
adds a pair of aliased properties ("totalSize" and "position".) It was
originally added for compatibility with Gecko.

Motivation

Gecko / Firefox removed this interface in version 22 (and deprecated in
FF10),

https://bugzilla.mozilla.org/show_bug.cgi?id=845631

hence the compatibility argument for supporting this interface and its
properties is no longer present. Usage data is also very low, and
coupled with the trivial renaming changes required for any content still
using the interface's properties, removal seems appropriate and
achievable without noteworthy upset.


Usage information from UseCounter

http://www.chromestatus.com/metrics/feature/timeline/popularity/316
(position - ~0.00225)
http://www.chromestatus.com/metrics/feature/timeline/popularity/317
(totalSize - ~0.00375)


Entry on chromestatus.com

None - https://code.google.com/p/chromium/issues/detail?id=357112 is the
relevant bug.

Compatibility Risk

Low. Removal would align with Gecko and Trident (which hasn't supported
these properties.)

[Adam Barth‏]

LGTM

[PhistucK‏]

For your information, some still use it without a fallback -

https://github.com/search?l=javascript&o=desc&q=%22e.totalSize%22&ref=searchresults&s=indexed&type=Code

These mainly come from an (apparently) old version of Emscripten.

A short deprecation period (even one release) would be a nice courtesy, though.

☆PhistucK

LGTM

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[PhistucK‏]

And the interface itself has some non JSDocs mentions as well -

https://github.com/search?l=javascript&o=desc&q=XMLHttpRequestProgressEvent&ref=searchresults&s=indexed&type=Code

☆PhistucK

[Eric Seidel‏]

Presumably none of those work in current Firefox either. Does IE
support this property? Presumably Safari still does?

I'm fine with either direct removal or deprecation for a release.

LGTM

[PhistucK‏]

Right, but Firefox and Internet Explorer are not so common on mobile. Do we have more mobile oriented numbers?

(Internet Explorer 11 does not show both of these on ProgressEvent and also does not have the mentioned interface)

Since the code to maintain this is really small and trivial anyway (it seems), it is not like we are in a rush.

☆PhistucK

[Sigbjorn Finne‏]

Den 11.08.2014 19:35, skreiv PhistucK:
> Right, but Firefox and Internet Explorer are not so common on mobile. Do we
> have more mobile oriented numbers?
>
> (Internet Explorer 11 does not show both of these on ProgressEvent and also
> does not have the mentioned interface)
>

Yes, as stated on the intent-to-remove.

> Since the code to maintain this is really small and trivial anyway (it
> seems), it is not like we are in a rush.
>

We can of course wait it out a little longer and go via deprecation, if
that's the consensus. FF removed it mid-2013, and I haven't come across
compat issues being reported.

Regarding deprecation and mobile-focused applications - do we have
data/known cases on deprecation reporting being effective for those? (It
strikes me as being a desktop UA-friendly user reporting mechanism.)

--sigbjorn

[Eric Seidel‏]

I know of no data showing that our deprecation messages do anything, no.

I expect an intrepid researcher could look at our historical usage
data and compare it to when features began logging deprecation
messages and see if there was correlation. :)

[David Benjamin‏]

Given that dividing by undefined just evaluates to NaN rather than throwing an exception, I suspect many uses will degrade gracefully anyway. The Emscripten one, for instance, will just set percentComplete to NaN. From there, I assume that calling an Emscripten-compiled function which expects an int will just convert it to 0 (NaN|0 = 0 because it converts to int32 first). And so the request will not give accurate progress until the load completes (the progress will stay at zero), but otherwise the page will not get horribly confused.

[Kouhei Ueno‏]

LGTM removing.

I wouldn't call XMLHttpRequestProgressEvent implementation very simple. We even have a throttler for this event, XMLHttpRequestProgressEventThrottle. Removing this reduces code complexity of XHR.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--

Kouhei Ueno

[PhistucK‏]

Do you have this throttler for the ProgressEvent of XMLHttpRequest as well?

☆PhistucK

[Kouhei Ueno‏]

On Mon, Aug 11, 2014 at 1:56 PM, PhistucK <phis...@gmail.com> wrote:

Do you have this throttler for the ProgressEvent of XMLHttpRequest as well?

Sorry I misunderstood the proposal. We need to keep the throttler anyway for the ProgressEvent.

I guess there is no significant difference in the code complexity then. Still LGTM to conform to the standards.

 

☆Phistu

--

Kouhei Ueno

[Sigbjorn Finne‏]

Den 11.08.2014 23:05, skreiv Kouhei Ueno:
> On Mon, Aug 11, 2014 at 1:56 PM, PhistucK <phis...@gmail.com> wrote:
>
>> Do you have this throttler for the ProgressEvent of XMLHttpRequest as well?
>>
> Sorry I misunderstood the proposal. We need to keep the throttler anyway
> for the ProgressEvent.

Yes, we still want to adhere to


https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#make-progress-notifications

(I can't find a corresponding constraint in the xhr.spec.whatwg.org spec
text, for some reason.)

--sigbjorn

[Domenic Denicola‏]

[+annevk]

From: blin...@chromium.org <blin...@chromium.org> on behalf of Sigbjorn Finne <s...@opera.com>

> (I can't find a corresponding constraint in the xhr.spec.whatwg.org spec text, for some reason.)

It was moved to Fetch: http://fetch.spec.whatwg.org/#concept-fetch

[Takeshi Yoshino‏]

LGTM (non API owner) though the maintenance cost is low so no hurry.

Takeshi

[dgla...@google.com‏]

LGTM.

[Sigbjorn Finne‏]

Den 15.08.2014 06:42, skreiv Takeshi Yoshino:
> LGTM (non API owner) though the maintenance cost is low so no hurry.
>

Thanks all for the input. Decided to proceed with a deprecation,

https://src.chromium.org/viewvc/blink?revision=180775&view=revision

I will re-visit removal towards the end of the year or so.

--sigbjorn

[bmdforha...@gmail.com‏]

[anastoru...@gmail.com‏]

[aph...@gmail.com‏]

so how do I buy the room?