Intent to remove: XMLHttpRequestProgressEvent

706 vues
Accéder directement au premier message non lu

Sigbjorn Finne

non lue,
11 août 2014, 12:15:4311/08/2014
à blink-dev

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

non lue,
11 août 2014, 12:44:4811/08/2014
à Sigbjorn Finne,blink-dev
LGTM

PhistucK

non lue,
11 août 2014, 13:13:1611/08/2014
à Adam Barth,Sigbjorn Finne,blink-dev
For your information, some still use it without a fallback -

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

non lue,
11 août 2014, 13:22:4711/08/2014
à Adam Barth,Sigbjorn Finne,blink-dev


PhistucK

Eric Seidel

non lue,
11 août 2014, 13:24:4411/08/2014
à PhistucK,Adam Barth,Sigbjorn Finne,blink-dev
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

non lue,
11 août 2014, 13:36:3011/08/2014
à Eric Seidel,Adam Barth,Sigbjorn Finne,blink-dev
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

non lue,
11 août 2014, 14:21:1111/08/2014
à PhistucK,Eric Seidel,Adam Barth,blink-dev
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

non lue,
11 août 2014, 14:23:4411/08/2014
à Sigbjorn Finne,PhistucK,Adam Barth,blink-dev
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

non lue,
11 août 2014, 15:08:5711/08/2014
à Eric Seidel,Sigbjorn Finne,PhistucK,Adam Barth,blink-dev
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

non lue,
11 août 2014, 16:54:5711/08/2014
à David Benjamin,Eric Seidel,Sigbjorn Finne,PhistucK,Adam Barth,blink-dev
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

non lue,
11 août 2014, 16:57:1311/08/2014
à Kouhei Ueno,David Benjamin,Eric Seidel,Sigbjorn Finne,Adam Barth,blink-dev
Do you have this throttler for the ProgressEvent of XMLHttpRequest as well?


PhistucK

Kouhei Ueno

non lue,
11 août 2014, 17:05:3311/08/2014
à PhistucK,David Benjamin,Eric Seidel,Sigbjorn Finne,Adam Barth,blink-dev
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

non lue,
11 août 2014, 17:16:4311/08/2014
à Kouhei Ueno,PhistucK,David Benjamin,Eric Seidel,Adam Barth,blink-dev
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

non lue,
11 août 2014, 17:35:2211/08/2014
à Sigbjorn Finne,Kouhei Ueno,PhistucK,Anne van Kesteren,David Benjamin,Eric Seidel,Adam Barth,blink-dev
[+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

non lue,
15 août 2014, 00:42:5015/08/2014
à Domenic Denicola,Sigbjorn Finne,Kouhei Ueno,PhistucK,Anne van Kesteren,David Benjamin,Eric Seidel,Adam Barth,blink-dev
LGTM (non API owner) though the maintenance cost is low so no hurry.

Takeshi

dgla...@google.com

non lue,
18 août 2014, 17:54:3718/08/2014
à blin...@chromium.org,dom...@domenicdenicola.com,s...@opera.com,kou...@google.com,phis...@gmail.com,ann...@annevk.nl,davi...@chromium.org,ese...@chromium.org,aba...@chromium.org
LGTM.

Sigbjorn Finne

non lue,
22 août 2014, 10:33:3022/08/2014
à blink-dev
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

non lue,
27 juil. 2016, 19:54:0827/07/2016
à blink-dev,s...@opera.com

anastoru...@gmail.com

non lue,
12 nov. 2017, 10:57:3412/11/2017
à blink-dev,s...@opera.com

aph...@gmail.com

non lue,
6 déc. 2019, 08:49:3106/12/2019
à blink-dev,s...@opera.com
so how do I buy the room?
Répondre à tous
Répondre à l'auteur
Transférer
0 nouveau message