[Bug 28505] Synchronous XHR removal makes patching Error.prepareStackTrace impossible

Status|NEW |RESOLVED --- Comment #2 from Anne <ann...@annevk.nl> --- If this continuous to be a problem, please contribute to this thread on GitHub: https://github.com/whatwg/xhr/issues/20 Thanks! -- You are receiving this mail because: You are on the CC list for the bug.

Re: [XHR] null response prop in case of invalid JSON

On Mon, Apr 25, 2016 at 8:10 PM, Kirill Dmitrenko <dmi...@yandex-team.ru> wrote: > I've found in the spec of XHR Level 2 that if a malformed JSON's received > from a server, the response property would be set to null. But null is a > valid JSON, so, if I understand correctly,

[XHR] null response prop in case of invalid JSON

Hi! I've found in the spec of XHR Level 2 that if a malformed JSON's received from a server, the response property would be set to null. But null is a valid JSON, so, if I understand correctly, there is no way to distinct a malformed JSON response from a response containing only 'null', which

Re: [XHR]

On Wed, Mar 16, 2016 at 10:29 AM, Tab Atkins Jr. wrote: > No, streams do not solve the problem of "how do you present a > partially-downloaded JSON object". They handle chunked data *better*, > so they'll improve "text" response handling, Also binary handling should be

Re: [XHR]

On Wed, Mar 16, 2016 at 1:54 PM, Gomer Thomas wrote: > but I need a cross-browser solution in the near future Another solution that I think would work cross-browser is to use "text/plain;charset=ISO-8859-15" as content-type. That way I *think* you can simply read

RE: [XHR]

, 2016 7:20 PM To: Hallvord R. M. Steen <hst...@mozilla.com> Cc: Gomer Thomas <go...@gomert-consulting.com>; WebApps WG <public-webapps@w3.org> Subject: Re: [XHR] Hallvord et al. Le 16 mars 2016 à 20:

Re: [XHR]

> On Mar 17, 2016, at 3:12 AM, Jonas Sicking wrote: > >> On Wed, Mar 16, 2016 at 10:29 AM, Tab Atkins Jr. >> wrote: >> No, streams do not solve the problem of "how do you present a >> partially-downloaded JSON object". They handle chunked data

RE: [XHR]

m> Cc: Hallvord Reiar Michaelsen Steen <hst...@mozilla.com>; WebApps WG <public-webapps@w3.org> Subject: Re: [XHR] Sounds like you want access to partial binary data. There's some propitiatory features in Firefox which lets you do this (added ages ago). See [1].

RE: [XHR]

lt;public-webapps@w3.org> Subject: Re: [XHR] On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas <go...@gomert-consulting.com> wrote: > According to IETF RFC 7230 all HTTP recipients “MUST be able to parse > the chunked transfer coding”. Th

Re: [XHR]

Thomas <go...@gomert-consulting.com> > Cc: WebApps WG <public-webapps@w3.org> > Subject: Re: [XHR] > >On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas > <go...@gomert-consulting.com> wrote: > >> According to IETF RFC 7230 all HTTP recip

RE: [XHR]

From: Gomer Thomas [mailto:go...@gomert-consulting.com] > [GT] It would be good to say this in the specification, and > reference > some sample source APIs. (This is an example of what I meant when I said it > is very difficult to read the specification unless one already knows

RE: [XHR]

From: Elliott Sprehn [mailto:espr...@chromium.org] > Can we get an idl definition too? You shouldn't need to read the algorithm to > know the return types. Streams, like promises/maps/sets, are not specced or implemented using the IDL type system. (Regardless, the Web IDL's return types are

Re: [XHR]

If I understand correctly, streams [1] with fetch should solve this use-case. [1] https://streams.spec.whatwg.org/ On Wed, Mar 16, 2016 at 7:10 AM Hallvord Reiar Michaelsen Steen < hst...@mozilla.com> wrote: > On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas > wrote:

RE: [XHR]

From: Gomer Thomas [mailto:go...@gomert-consulting.com] > I looked at the Streams specification, and it seems pretty immature and > underspecified. I’m not sure it is usable by someone who doesn’t already know > how it is supposed to work before reading the specification. How many of the >

RE: [XHR]

s WG <public-webapps@w3.org> Subject: Re: [XHR] If I understand correctly, streams [1] with fetch should solve this use-case. [1] https://streams.spec.whatwg.org/ On Wed, Mar 16, 2016 at 7:10 AM Hallvord Reiar Michaelsen Steen <hst...@mozilla.com <mailto:hst...@mozilla.com&g

RE: [XHR]

Can we get an idl definition too? You shouldn't need to read the algorithm to know the return types. On Mar 17, 2016 12:09 PM, "Domenic Denicola" wrote: > From: Gomer Thomas [mailto:go...@gomert-consulting.com] > > > I looked at the Streams specification, and it seems pretty

Re: [XHR]

On Wed, Mar 16, 2016 at 5:10 AM, Jonathan Garbee wrote: > On Wed, Mar 16, 2016 at 7:10 AM Hallvord Reiar Michaelsen Steen > wrote: >> On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas >> wrote: >> >> > According to IETF

RE: [XHR]

;; 'Hallvord Reiar Michaelsen Steen' <hst...@mozilla.com> Cc: 'WebApps WG' <public-webapps@w3.org> Subject: RE: [XHR] From: Gomer Thomas [mailto:go...@gomert-consulting.com] > I looked at the Streams specifi

Re: [XHR]

On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas wrote: > According to IETF RFC 7230 all HTTP recipients “MUST be able to parse the > chunked transfer coding”. The logical interpretation of this is that > whenever possible HTTP recipients should deliver the chunks to

[XHR]

Dear Colleagues, The XHR specification has one very unsatisfactory aspect. It appears that W3C and WHATWG are snubbing your noses at IETF. According to IETF RFC 7230 all HTTP recipients "MUST be able to parse the chunked transfer coding". The logical interpretation of this is tha

Re: [XHR] Error type when setting request headers.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Yves, On 09/29/2015 03:25 PM, Yves Lafon wrote: > Hi, In XHR [1], setRequestHeader is defined by this: [[ void > setRequestHeader(ByteString name, ByteString value); ]] It has a > note: [[ Throws a SyntaxError exception if name is not

[XHR]

=[xhr]

RE async: false being deprecated There's still occasionally a need for a call from client javascript back to server and wait on results. Example: an inline call from client javascript to PHP on server to authenticate an override password as part of a client-side operation. The client-side

Re: =[xhr]

an override password as part of a client-side operation. The client-side experience could be managed with a sane timeout param - eg return false if no response after X seconds (or ms). Nothing prevents you from waiting on an XHR to return before continuing. Doing it with async operations

=[xhr]

This is causing grepolis to lag significantly. Please fix it Charles T Perry

[Bug 28505] New: Synchronous XHR removal makes patching Error.prepareStackTrace impossible

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28505 Bug ID: 28505 Summary: Synchronous XHR removal makes patching Error.prepareStackTrace impossible Product: WebAppsWG Version: unspecified Hardware: PC OS

Re: [XHR] UTF-16 - do content sniffing or not?

Which MIME type did you use in the response? BOM sniffing in XML is non-normative IIRC. For other types, see below. It's text/plain - seems I definitely need one test with an XML response too.. and one with JSON. [[ If charset is null, set charset to utf-8. Return the result of running

Re: [XHR] UTF-16 - do content sniffing or not?

On Mon, Mar 23, 2015 at 1:45 PM, Simon Pieters sim...@opera.com wrote: On Sun, 22 Mar 2015 23:13:20 +0100, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: Given a server which sends UTF-16 data with a UTF-16 BOM but does *not* send charset=UTF-16 in the Content-Type header -

Re: [XHR] UTF-16 - do content sniffing or not?

On Sun, 22 Mar 2015 23:13:20 +0100, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: Hi, I've just added a test loading UTF-16 data with XHR, and it exposes an implementation difference that should probably be discussed: Given a server which sends UTF-16 data with a UTF-16 BOM

Re: [XHR] UTF-16 - do content sniffing or not?

On Mon, 23 Mar 2015 14:32:27 +0100, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: On Mon, Mar 23, 2015 at 1:45 PM, Simon Pieters sim...@opera.com wrote: On Sun, 22 Mar 2015 23:13:20 +0100, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: Given a server which sends

[XHR] UTF-16 - do content sniffing or not?

Hi, I've just added a test loading UTF-16 data with XHR, and it exposes an implementation difference that should probably be discussed: Given a server which sends UTF-16 data with a UTF-16 BOM but does *not* send charset=UTF-16 in the Content-Type header - should the browser detect the encoding

Re: =[xhr]

Hi, Thank you for your feedback. Please see the archives for previous iterations of this discussion, e.g. https://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0084.html (and click next in thread). On 29.01.2015 21:04, LOUIFI, Bruno wrote: Hi, I am really disappointed when I saw in

=[xhr]

Hi, I am really disappointed when I saw in Chrome debugger that the XMLHttpRequest.open() is deprecating the synchronous mode. This is was the worst news I red since I started working on web applications. I don't know if you release the negative impacts on our professional applications. We

Re: =[xhr]

I think there are several different scenarios under consideration. 1. The author says Content-Length 100, writes 50 bytes, then closes the stream. 2. The author says Content-Length 100, writes 50 bytes, and never closes the stream. 3. The author says Content-Length 100, writes 150 bytes,

RE: =[xhr]

From: Rui Prior [mailto:rpr...@dcc.fc.up.pt] IMO, exposing such degree of (low level) control should be avoided. I disagree on principle :). If we want true webapps we need to not be afraid to give them capabilities (like POSTing data to S3) that native apps have. In cases where the size of

RE: =[xhr]

From: Rui Prior [mailto:rpr...@dcc.fc.up.pt] If you absolutely need to stream content whose length is unknown beforehand to a server not supporting ckunked encoding, construct your web service so that it supports multiple POSTs (or whatever), one per piece of data to upload.

Re: =[xhr]

On Wed, Nov 19, 2014 at 1:45 AM, Domenic Denicola d...@domenic.me wrote: From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren On Tue, Nov 18, 2014 at 12:50 PM, Takeshi Yoshino tyosh...@google.com wrote: How about padding the remaining bytes

Re: =[xhr]

On Tue, Nov 18, 2014 at 5:45 AM, Domenic Denicola d...@domenic.me wrote: That would be very sad. There are many servers that will not accept chunked upload (for example Amazon S3). The only way I could imagine us doing this is by setting the Content-Length header value through an option (not

RE: =[xhr]

From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren The only way I could imagine us doing this is by setting the Content-Length header value through an option (not through Headers) and by having the browser enforce the specified length somehow.

Re: =[xhr]

On Tue, Nov 18, 2014 at 10:34 AM, Domenic Denicola d...@domenic.me wrote: I still think we should just allow the developer full control over the Content-Length header if they've taken full control over the contents of the request body (by writing to its stream asynchronously and piecemeal).

Re: =[xhr]

How about padding the remaining bytes forcefully with e.g. 0x20 if the WritableStream doesn't provide enough bytes to us? Takeshi On Tue, Nov 18, 2014 at 7:01 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Nov 18, 2014 at 10:34 AM, Domenic Denicola d...@domenic.me wrote: I still think

Re: =[xhr]

On Tue, Nov 18, 2014 at 12:50 PM, Takeshi Yoshino tyosh...@google.com wrote: How about padding the remaining bytes forcefully with e.g. 0x20 if the WritableStream doesn't provide enough bytes to us? How would that work? At some point when the browser decides it wants to terminate the fetch

RE: =[xhr]

From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren On Tue, Nov 18, 2014 at 12:50 PM, Takeshi Yoshino tyosh...@google.com wrote: How about padding the remaining bytes forcefully with e.g. 0x20 if the WritableStream doesn't provide enough bytes to

Re: =[xhr]

I think there are several different scenarios under consideration. 1. The author says Content-Length 100, writes 50 bytes, then closes the stream. Depends on what exactly closing the stream does: (1) Closing the stream includes closing the the TCP connection = the body of the HTTP message

Re: CfC: publish WG Note of XHR Level 2; deadline November 14

On 11/7/14 11:46 AM, Arthur Barstow wrote: this is a Call for Consensus to: a) Publish a gutted WG Note of the spec (see [Draft-Note]) FYI, this WG Note has been published http://www.w3.org/TR/2014/NOTE-XMLHttpRequest2-20141118/.

=[xhr]

AFAIK, there is currently no way of using XMLHttpRequest to make a POST using Transfer-Encoding: Chunked. IMO, this would be a very useful feature for repeatedly sending short messages to a server. You can always make POSTs repeatedly, one per chunk, and arrange for the server to glue the chunks

Re: =[xhr]

On Fri, Nov 14, 2014 at 7:49 PM, Rui Prior rpr...@dcc.fc.up.pt wrote: You can always make POSTs repeatedly, one per chunk, and arrange for the server to glue the chunks together, but for short messages this process adds a lot of overhead (a full HTTP request per chunk, with full headers for

Re: =[xhr]

We're adding Streams API https://streams.spec.whatwg.org/ based response body receiving feature to the Fetch API See - https://github.com/slightlyoff/ServiceWorker/issues/452 - https://github.com/yutakahirano/fetch-with-streams Similarly, using WritableStream + Fetch API, we could allow for

RE: =[xhr]

If I recall how Node.js does this, if you don’t provide a `Content-Length` header, it automatically sets `Transfer-Encoding: chunked` the moment you start writing to the body. What do we think of that kind of behavior for fetch requests? My opinion is that it’s pretty convenient, but I am not

Re: =[xhr]

On Mon, Nov 17, 2014 at 3:50 PM, Domenic Denicola d...@domenic.me wrote: What do we think of that kind of behavior for fetch requests? I'm not sure we want to give a potential hostile piece of script that much control over what goes out. Being able to lie about Content-Length would be a new

Re: =[xhr]

On Tue, Nov 18, 2014 at 12:11 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Nov 17, 2014 at 3:50 PM, Domenic Denicola d...@domenic.me wrote: What do we think of that kind of behavior for fetch requests? I'm not sure we want to give a potential hostile piece of script that much

RE: =[xhr]

From: Takeshi Yoshino [mailto:tyosh...@google.com] On Tue, Nov 18, 2014 at 12:11 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Nov 17, 2014 at 3:50 PM, Domenic Denicola d...@domenic.me wrote: What do we think of that kind of behavior for fetch requests? I'm not sure we want to give

Re: =[xhr]

On Tue, Nov 18, 2014 at 1:45 PM, Domenic Denicola d...@domenic.me wrote: From: Takeshi Yoshino [mailto:tyosh...@google.com] On Tue, Nov 18, 2014 at 12:11 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Nov 17, 2014 at 3:50 PM, Domenic Denicola d...@domenic.me wrote: What do we

RE: CfC: publish WG Note of XHR Level 2; deadline November 14

From: cha...@yandex-team.ru [mailto:cha...@yandex-team.ru] That doesn't work with the way W3C manages its work and paper trails. I guess I was just inspired by Mike Smith earlier saying something along the lines of don't let past practice constrain your thinking as to what can be done in

Re: CfC: publish WG Note of XHR Level 2; deadline November 14

08.11.2014, 14:46, Domenic Denicola d...@domenic.me: From: cha...@yandex-team.ru [mailto:cha...@yandex-team.ru]  That doesn't work with the way W3C manages its work and paper trails. I guess I was just inspired by Mike Smith earlier saying something along the lines of don't let past practice

CfC: publish WG Note of XHR Level 2; deadline November 14

During WebApps' XHR discussion on October 27, no one expressed interest to work on XHR L2 [Mins]. The last TR of XHR L2 was published in January 2012 [WD] thus that version should be updated to clarify work has stopped. As such, this is a Call for Consensus to: a) Publish a gutted WG Note

Re: CfC: publish WG Note of XHR Level 2; deadline November 14

On Fri, Nov 7, 2014 at 5:46 PM, Arthur Barstow art.bars...@gmail.com wrote: https://dvcs.w3.org/hg/xhr/raw-file/default/TR/XHRL2-Note-2014-Nov.html Should this not include a reference to https://xhr.spec.whatwg.org/? -- https://annevankesteren.nl/

Re: CfC: publish WG Note of XHR Level 2; deadline November 14

On Nov 7, 2014, at 17:55, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Nov 7, 2014 at 5:46 PM, Arthur Barstow art.bars...@gmail.com wrote: https://dvcs.w3.org/hg/xhr/raw-file/default/TR/XHRL2-Note-2014-Nov.html Should this not include a reference to https://xhr.spec.whatwg.org

Re: CfC: publish WG Note of XHR Level 2; deadline November 14

07.11.2014, 18:28, Domenic Denicola d...@domenic.me:  On Nov 7, 2014, at 17:55, Anne van Kesteren ann...@annevk.nl wrote:  On Fri, Nov 7, 2014 at 5:46 PM, Arthur Barstow art.bars...@gmail.com wrote:  https://dvcs.w3.org/hg/xhr/raw-file/default/TR/XHRL2-Note-2014-Nov.html  Should

Re: CfC: publish WG Note of XHR Level 2; deadline November 14

On 11/7/14 1:05 PM, cha...@yandex-team.ru wrote: 07.11.2014, 18:28, Domenic Denicola d...@domenic.me: On Nov 7, 2014, at 17:55, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Nov 7, 2014 at 5:46 PM, Arthur Barstow art.bars...@gmail.com wrote: https://dvcs.w3.org/hg/xhr/raw-file

[Bug 25090] Use document's encoding for url query encoding in XHR open()

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25090 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED

WebApps-ACTION-747: Start a cfc to gut xhr l2 and publish a wg note

WebApps-ACTION-747: Start a cfc to gut xhr l2 and publish a wg note http://www.w3.org/2008/webapps/track/actions/747 Assigned to: Arthur Barstow

Re: [xhr] Questions on the future of the XHR spec, W3C snapshot

[ Apologies for top posting ] I just added a 11:30-12:00 time slot on Monday October 27 for XHR: https://www.w3.org/wiki/Webapps/November2014Meeting#Agenda_Monday_October_27 I believe Jungkee will be at the meeting so, Hallvord and Julian please join via the phone bridge and/or IRC if you can

Re: Questions on the future of the XHR spec, W3C snapshot

. XHR in particular seems like a good opportunity for the W3C to reciprocate, since with both specs there's a pretty clear sense that we all want what's best for the web and nobody wants to have their own outdated copy just for the sake of owning it. In that same spirit, I'd suggest that everybody

Re: Questions on the future of the XHR spec, W3C snapshot

or installing a redirection to it. Without the Fetch refactoring, it seems that a new TR based on the old snapshot won't be satisfying the forward compatibility sooner or later. E.g., web authors will also expect an XHR request will fire a fetch event on a service worker, but the old

Re: Questions on the future of the XHR spec, W3C snapshot

On Mon, Oct 20, 2014 at 12:46 PM, cha...@yandex-team.ru wrote: While it seems bleeding edge XHR specs will be in flux for some time (e.g. if Anne takes the spec of record and dismembers it into fetch, I presume he won't get that done within a couple of months...) To be clear, XMLHttpRequest

Re: [xhr] Questions on the future of the XHR spec, W3C snapshot

or REC with a normative reference to a WHATWG spec, the line of logic implied by that statement would be a great way to help achieve that. (Huh? I'm on record for the opposite.) If Hallvord and the other editors of the W3C XHR spec want to reference the Fetch spec, then they should reference

Re: test coverage data for XHR spec

On Sun, Oct 19, 2014 at 2:28 PM, Hallvord R. M. Steen hst...@mozilla.com wrote: Here you go, Anne: https://github.com/whatwg/xhr/pull/17 (And I'd guesstimate perhaps half of the meta data is wrong for the WHATWG version of XHR by now - if you want, I can add the text (beta) or something

Re: test coverage data for XHR spec

Here you go, Anne: https://github.com/whatwg/xhr/pull/17 (And I'd guesstimate perhaps half of the meta data is wrong for the WHATWG version of XHR by now - if you want, I can add the text (beta) or something like that to the checkbox label). Art: Wondering aloud ... adding this functionality

Re: [xhr] Questions on the future of the XHR spec, W3C snapshot

, the WHATWG version is now quite heavily refactored to be XHR+Fetch. It's no longer clear to me whether pushing forward to ship XHR2 stand-alone is the right thing to do.. The Plan of Record (PoR) is still to continue to work on both versions of XHR (historically called L1 and L2. However, I agree

Re: [xhr] Questions on the future of the XHR spec, W3C snapshot

However, the WHATWG version is now quite heavily refactored to be XHR+Fetch. It's no longer clear to me whether pushing forward to ship XHR2 stand-alone is the right thing to do.. (For those not familiar with WebApps' XHR TR publication history, the latest snapshots are: Level1 http

Re: [xhr] Questions on the future of the XHR spec, W3C snapshot

be a great way to help achieve that. If Hallvord and the other editors of the W3C XHR spec want to reference the Fetch spec, then they should reference the Fetch spec. As such, we could do c) but with respect to helping to set realistic expectations for spec that references such a version of XHR, I think

RE: Questions on the future of the XHR spec, W3C snapshot

to https://domparsing.spec.whatwg.org/ redirected immediately to https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html. This kind of solution seems optimal to me because it removes any potential confusion from the picture. XHR in particular seems like a good opportunity for the W3C to reciprocate

Re: RE: Questions on the future of the XHR spec, W3C snapshot

refactoring, it seems that a new TR based on the old snapshot won't be satisfying the forward compatibility sooner or later. E.g., web authors will also expect an XHR request will fire a fetch event on a service worker, but the old snapshot will still remain with a pointer to a fetch in HTML spec

Re: Questions on the future of the XHR spec, W3C snapshot

On Fri, Oct 17, 2014 at 6:05 PM, Domenic Denicola dome...@domenicdenicola.com wrote: No need to make this a vs.; we're all friends here :). FWIW previous specs which have needed to become abandoned because they were superceded by another spec have been re-published as NOTEs pointing to the

Re: [xhr] Questions on the future of the XHR spec, W3C snapshot

On 10/17/14, 8:19 PM, Hallvord R. M. Steen wrote: a) Ship a TR based on the spec just *before* the big Fetch refactoring. If we want to publish something at all, I think this is the most reasonable option, frankly. I have no strong opinions on whether this is done REC-track or as a Note, I

Re: test coverage data for XHR spec

I can send you a PR for that JSON file if you wish. For example make a new folder called testcoveragedata or something to put the JSON file inside? If all we need is a single JSON file and maybe a script let's put them in the top-level directory. Should I send you a PR now so you or I can

Re: test coverage data for XHR spec

On Fri, Oct 17, 2014 at 10:55 PM, Hallvord R. M. Steen hst...@mozilla.com wrote: Should I send you a PR now so you or I can play our with the linking and styling (I'm very much aware that what the JS currently does to the spec is ugly), or should I wait a few weeks and try to find time to

[xhr] Questions on the future of the XHR spec, W3C snapshot

to this thread could be to-the-point and avoid the ideological swordmanship as much as possible. When accepting editor positions, we first believed that we could ship a TR of XHR relatively quicky. (I think of that fictive TR as XHR 2 although W3C haven't released any XHR 1, simply because CORS

RE: Questions on the future of the XHR spec, W3C snapshot

17, 2014 20:19 To: public-webapps Subject: [xhr] Questions on the future of the XHR spec, W3C snapshot Apologies in advance that this thread will deal with something that's more in the realm of politics. First, I'm writing as one of the W3C-appointed editors of the snapshot the WebApps WG

[Bug 27033] New: XHR request termination doesn't terminate queued tasks

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27033 Bug ID: 27033 Summary: XHR request termination doesn't terminate queued tasks Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW

Re: test coverage data for XHR spec

On Sat, Oct 11, 2014 at 7:09 PM, Hallvord R. M. Steen hst...@mozilla.com wrote: I can send you a PR for that JSON file if you wish. For example make a new folder called testcoveragedata or something to put the JSON file inside? If all we need is a single JSON file and maybe a script let's put

Re: test coverage data for XHR spec

On Mon, Oct 6, 2014 at 3:04 PM, Hallvord R. M. Steen hst...@mozilla.com wrote: If you do try this on xhr.spec.whatwg.org, you'll see that quite a lot of the meta data is still valid I see. We could make xhr.spec.whatwg.org offer a checkbox that would add these links. That would rock :) We

[Bug 25090] Use document's encoding for url query encoding in XHR open()

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25090 Bug 25090 depends on bug 23822, which changed state. Bug 23822 Summary: Should the EventSource, Worker, and SharedWorker constructors resolve the URL using utf-8? https://www.w3.org/Bugs/Public/show_bug.cgi?id=23822 What

test coverage data for XHR spec

Hi, partly quoting myself from https://github.com/w3c/web-platform-tests/pull/1272 : Nearly all tests in the XHR test suite have (potentially outdated) meta data linking them to specific assertations in the spec. (Technically this is a set of space-separated XPath expressions for each link

Re: test coverage data for XHR spec

and adding functionality and all that, but in general the observed behaviour should be mostly stable - right? I hope the tests and assertations are still mostly valid (and if something disagrees with your XHR+Fetch that's probably a bug we'll fix at some point) - the only issue you have should

Re: test coverage data for XHR spec

On Mon, Oct 6, 2014 at 3:04 PM, Hallvord R. M. Steen hst...@mozilla.com wrote: If you do try this on xhr.spec.whatwg.org, you'll see that quite a lot of the meta data is still valid - it does add plenty of spec links, while warning in the console about the entries that need updating to match

RE: test coverage data for XHR spec

Very cool work Hallvord! This is exactly the kind of stuff that we need more of for today's specs, IMO. From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren On Mon, Oct 6, 2014 at 3:04 PM, Hallvord R. M. Steen hst...@mozilla.com wrote: If you do

=[xhr] Expose XMLHttpRequest priority

. That is, the API should expose the full set of priorities the browser supports. If my application wants to prioritize an XHR over some browser-initiated request, it should be allowed to do so. The more control over priority available, the better a customer experience can be built. For example, at the logical

Re: =[xhr] Expose XMLHttpRequest priority

On Tue, Sep 30, 2014 at 10:25 AM, Chad Austin caus...@gmail.com wrote: What will it take to get this added to the spec? There's been a pretty long debate on the WHATWG mailing list how to prioritize fetches of all things. I recommend contributing there. I don't think we should focus on just

Re: =[xhr] Expose XMLHttpRequest priority

things. I recommend contributing there. I don't think we should focus on just XMLHttpRequest. Hi Anne, Thanks for the quick response. Is this something along the lines of a SupportsPriority interface that XHR, various DOM nodes, and such would implement? Can you point me to the existing

Re: =[xhr] Expose XMLHttpRequest priority

on the WHATWG mailing list how to prioritize fetches of all things. I recommend contributing there. I don't think we should focus on just XMLHttpRequest. Hi Anne, Thanks for the quick response. Is this something along the lines of a SupportsPriority interface that XHR, various DOM nodes

RE: =[xhr]

:09 To: Robert Hanson Cc: David Rajchenbach-Teller; public-webapps; Greeves, Nick; Olli Pettay Subject: Re: =[xhr] ES6 is short for ECMAScript, 6th Edition, which is the next version of the standard specification that underlies the JavaScript programming language. All modern browsers currently

Re: =[xhr]

Java - JavaScript that works totally asynchronously is the plan. Should have that working relatively soon. jmolScript here x = load(file00+ (++i) + .pdb) /jmolScript here but we can live with that. Bob Hanson ​

Re: =[xhr]

. *From:* James M. Greene [mailto:james.m.gre...@gmail.com] *Sent:* Friday, September 5, 2014 05:09 *To:* Robert Hanson *Cc:* David Rajchenbach-Teller; public-webapps; Greeves, Nick; Olli Pettay *Subject:* Re: =[xhr] ES6 is short for ECMAScript, 6th Edition, which is the next version

Re: {Spam?} Re: [xhr]

On Wed, Sep 3, 2014 at 11:11 PM, Jonas Sicking jo...@sicking.cc wrote: Agreed. Making it a conformance requirement not to use sync XHR seems like a good idea. It is a conformance requirement. Developers must not pass false for the async argument when the JavaScript global environment

Re: =[xhr]

SO glad to hear that. I expect to have a fully asynchronous version of JSmol available for testing soon. It will require some retooling of sophisticated sites, but nothing that a typical JavaScript developer of pages utilizing JSmol cannot handle. I still have issues with the language in the w3c

Re: =[xhr]

The sole reason for these sync XHRs, if you recall the OP, is to pull in libraries that are only referenced deep in a call stack, so as to avoid having to include *all* the libraries in the initial download. If that is true, wouldn't it better for him to switch over to ES6 Module imports and

Re: =[xhr]

On 04/09/14 14:31, James M. Greene wrote: The sole reason for these sync XHRs, if you recall the OP, is to pull in libraries that are only referenced deep in a call stack, so as to avoid having to include *all* the libraries in the initial download. If that is true, wouldn't it better for

Re: =[xhr]

True that ES6 Modules are not quite ready yet but the existing transpilers for it also convert to asynchronously loading AMD syntax, a la RequireJS. Still seems a perfect fit for this use case, and Robert may not be aware that such functionality is forthcoming to solve his issue (and obviously

  1   2   3   4   5   6   7   8   9   10   >