Intent to remove: XMLHttpRequestProgressEvent

744 weergaven
Naar het eerste ongelezen bericht

Sigbjorn Finne

ongelezen,
11 aug. 2014 12:15:4311-08-2014
aan 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

ongelezen,
11 aug. 2014 12:44:4811-08-2014
aan Sigbjorn Finne, blink-dev
LGTM

PhistucK

ongelezen,
11 aug. 2014 13:13:1611-08-2014
aan 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

ongelezen,
11 aug. 2014 13:22:4711-08-2014
aan Adam Barth, Sigbjorn Finne, blink-dev


PhistucK

Eric Seidel

ongelezen,
11 aug. 2014 13:24:4411-08-2014
aan 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

ongelezen,
11 aug. 2014 13:36:3011-08-2014
aan 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

ongelezen,
11 aug. 2014 14:21:1111-08-2014
aan 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

ongelezen,
11 aug. 2014 14:23:4411-08-2014
aan 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

ongelezen,
11 aug. 2014 15:08:5711-08-2014
aan 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

ongelezen,
11 aug. 2014 16:54:5711-08-2014
aan 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

ongelezen,
11 aug. 2014 16:57:1311-08-2014
aan 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

ongelezen,
11 aug. 2014 17:05:3311-08-2014
aan 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

ongelezen,
11 aug. 2014 17:16:4311-08-2014
aan 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

ongelezen,
11 aug. 2014 17:35:2211-08-2014
aan 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

ongelezen,
15 aug. 2014 00:42:5015-08-2014
aan 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

ongelezen,
18 aug. 2014 17:54:3718-08-2014
aan 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

ongelezen,
22 aug. 2014 10:33:3022-08-2014
aan 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

ongelezen,
27 jul. 2016 19:54:0827-07-2016
aan blink-dev, s...@opera.com

anastoru...@gmail.com

ongelezen,
12 nov. 2017 10:57:3412-11-2017
aan blink-dev, s...@opera.com

aph...@gmail.com

ongelezen,
6 dec. 2019 08:49:3106-12-2019
aan blink-dev, s...@opera.com
so how do I buy the room?
Allen beantwoorden
Auteur beantwoorden
Doorsturen
0 nieuwe berichten