W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

Re: "Officially" deprecating main-thread synchronous XHR?

From: James Greene <james.m.greene@gmail.com>
Date: Fri, 7 Feb 2014 19:19:17 -0600
Message-ID: <CALrbKZif1ynpwYqo=2w1D=9Zt=BbWTCx25BwSZ67A=czcy-Zug@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Domenic Denicola <domenic@domenicdenicola.com>, public-webapps <public-webapps@w3.org>, olli@pettay.fi, Jonas Sicking <jonas@sicking.cc>, Hallvord Steen <hsteen@mozilla.com>
There are certain situations where sync XHRs are, in fact, required...
unless we make other accommodations. For example, in the Clipboard API,
developers are allowed to inject into the clipboard as a semi-trusted event
during the event handling phase of certain user-initiated events (e.g.
`click`).[1]  This has not yet been implemented in any browsers yet.

However, if browser vendors choose to treat this scenario as it is treated
for Flash clipboard injection, then the semi-trusted state ends after the
default action for that event would occur.[2]

For Flash clipboard injection, this means that any required "on-demand"
XHRs must be resolved synchronously. For the DOM Clipboard API, it would be
nice to either still be able to use sync XHRs or else we would need to
specially authorize async XHRs that are started during the semi-trusted
state to have their completion handlers also still resolve/execute in a
semi-trusted state.

cc: Hallvord R. M. Steen

[1] http://dev.w3.org/2006/webapi/clipops/clipops.html#semi-trusted-event

[2]
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/desktop/Clipboard.html#setData()

Sincerely,
    James Greene
    Sent from my [smart?]phone
On Feb 7, 2014 2:55 PM, "Maciej Stachowiak" <mjs@apple.com> wrote:

>
> On Feb 7, 2014, at 9:18 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>
> On Feb 7, 2014 8:57 AM, "Domenic Denicola" <domenic@domenicdenicola.com>
> wrote:
> >
> > From: Olli Pettay <Olli.Pettay@helsinki.fi>
> >
> > > And at least we'd improve responsiveness of those websites which stop
> using sync XHR because of the warning.
> >
> > I think this is a great point that makes such an effort worthwhile even
> if it ends up not leading to euthanizing sync XHR.
>
> Agreed. I think for this to be effective we need to get multiple browser
> vendors being willing to add such a warning. We would also need to add text
> to the various versions of the spec (whatwg and w3c).
>
> Which browsers are game? (I think mozilla is). Which spec editors are?
>
> I usually hate deprecation warnings because I think they are ineffective
> and time-wasting. But this case may be worthy of an exception. In addition
> to console warnings in browsers and the alert in the spec, it might be
> useful to have a concerted documentation and outreach effort (e.g. blog
> posts on the topic) as an additional push to get Web developers to stop
> using sync XHR.
>
> Regards,
> Maciej
>
>
>
>
Received on Saturday, 8 February 2014 01:19:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:21 UTC