Re: Extending createObjectUrl to MediaStream?
On Tue, Sep 3, 2013 at 12:29 AM, Robert O'Callahan rob...@ocallahan.org wrote: What are your use-cases where they're not the same? More importantly, what are the use-cases where they cannot be made the same by the developer? E.g. embedding a widget for video or audio manipulation. The widget could be written by a third-party of sorts. We're lifting the origin restriction on Blob too, or at least, I believe that's still the plan. If you want to transfer the object to this other global it seems fine to do so since you could also transfer the data in some other way. -- http://annevankesteren.nl/
Re: [XHR] Event firing order. XMLHttpRequestUpload then XMLHttpRequest or reverse
On Fri, Aug 2, 2013 at 2:13 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jul 30, 2013 at 10:25 AM, Takeshi Yoshino tyosh...@google.com wrote: Change on 2010/09/13 http://dev.w3.org/cvsweb/2006/webapi/XMLHttpRequest-2/Overview.src.html.diff?r1=1.138;r2=1.139;f=h reversed the order of event firing for request error algorithm and send() method to XHRUpload-then-XHR. send() (only loadstart event) and abort() method are still specified to fire events in XHR-then-XHRUpload order. Is this intentional or we should make them consistent? We should make them consistent in some manner. Firing on the main object last makes sense to me. It also makes some amount of conceptual sense to do the reverse for when the fetching starts, but I feel less strongly about that. In the spec, we have three cancels - cancel an instance of fetch algorithm - cancel network activity - cancel a request The spec says Cancel a request is an abort error which fires events in XHR-XHRUpload order, but abort() fires events in XHR-XHRUpload order. It was confusing so I filed this bug. First and at least, I'd like to make this clear. What does cancel a request correspond to? Re: loadstart, I don't have strong opinion, too.
Re: Extending createObjectUrl to MediaStream?
On 2013-09-03 01:29, Robert O'Callahan wrote: What are your use-cases where they're not the same? More importantly, what are the use-cases where they cannot be made the same by the developer? E.g. the main page delegating communication to someone else (perhaps via an iFrame). If the MediaStream is a transferable object the incoming MediaStream can be transferred to the main page, which in turn can control layout and rendering. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * *
Re: Extending createObjectUrl to MediaStream?
On 09/03/2013 10:27 AM, Stefan Håkansson LK wrote:
On 2013-09-03 01:29, Robert O'Callahan wrote:
What are your use-cases where they're not the same? More importantly,
what are the use-cases where they cannot be made the same by the developer?
E.g. the main page delegating communication to someone else (perhaps via
an iFrame). If the MediaStream is a transferable object the incoming
MediaStream can be transferred to the main page, which in turn can
control layout and rendering.
One interesting thing about a MediaStream is that it's got multiple
links to the world around it. In particular, it can be connected to
multiple downstream objects.
This means that what happens to its peers when one transfers it has to
be defined.
For instance, if MediaStream were transferable, could I do this?
GetUserMedia(., success, failure)
function success(stream) {
myVideoTag.srcObject = stream
stream.transfer(myWorker)
}
and after this - would the video stop playing (because the stream is
gone from my context), or not?
[Bug 23102] Reset response entity bodies
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23102 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Anne ann...@annevk.nl --- https://github.com/whatwg/xhr/commit/459fa4a4748f3731894a31675056efc975539c94 -- You are receiving this mail because: You are on the CC list for the bug.
Re: Extending createObjectUrl to MediaStream?
On 2013-09-03 12:01, Harald Alvestrand wrote:
On 09/03/2013 10:27 AM, Stefan Håkansson LK wrote:
On 2013-09-03 01:29, Robert O'Callahan wrote:
What are your use-cases where they're not the same? More importantly,
what are the use-cases where they cannot be made the same by the developer?
E.g. the main page delegating communication to someone else (perhaps via
an iFrame). If the MediaStream is a transferable object the incoming
MediaStream can be transferred to the main page, which in turn can
control layout and rendering.
One interesting thing about a MediaStream is that it's got multiple
links to the world around it. In particular, it can be connected to
multiple downstream objects.
This means that what happens to its peers when one transfers it has to
be defined.
For instance, if MediaStream were transferable, could I do this?
GetUserMedia(., success, failure)
function success(stream) {
myVideoTag.srcObject = stream
stream.transfer(myWorker)
}
and after this - would the video stop playing (because the stream is
gone from my context), or not?
I think it should stop playing since the object srcObject references is
gone. (It would work differently with createObjecURL + myVideoTag.src
since that would only be a handle to an underlying resource)
If you'd like it to continue playing you'd have to clone the MediaStream
and transfer the clone.
Re: [XHR] Event firing order. XMLHttpRequestUpload then XMLHttpRequest or reverse
On Tue, Sep 3, 2013 at 9:18 AM, Takeshi Yoshino tyosh...@google.com wrote: In the spec, we have three cancels - cancel an instance of fetch algorithm - cancel network activity These are the same. Attempted to clarify. - cancel a request This is the end user terminate, correct? The spec says Cancel a request is an abort error which fires events in XHR-XHRUpload order, but abort() fires events in XHR-XHRUpload order. It was confusing so I filed this bug. First and at least, I'd like to make this clear. What does cancel a request correspond to? Re: loadstart, I don't have strong opinion, too. I aligned abort() with end user abort now. Would you like to be acknowledged as Takeshi Yoshino? If you can give me your name in kanji I can include that too. See e.g. http://encoding.spec.whatwg.org/#acknowledgments for some examples. See http://xhr.spec.whatwg.org/ for the updated text. And https://github.com/whatwg/xhr/commits for an overview of the changes. -- http://annevankesteren.nl/
Re: Extending createObjectUrl to MediaStream?
On Tue, Sep 3, 2013 at 12:48 PM, Stefan Håkansson LK stefan.lk.hakans...@ericsson.com wrote: I think it should stop playing since the object srcObject references is gone. (It would work differently with createObjecURL + myVideoTag.src since that would only be a handle to an underlying resource) The object is not gone, it's neutered. That could mean e.g. that instead you'd get black and no sound. Kinda depends on how you define a neutered MediaStream to work. -- http://annevankesteren.nl/
Re: Extending createObjectUrl to MediaStream?
On 2013-09-03 14:02, Anne van Kesteren wrote: On Tue, Sep 3, 2013 at 12:48 PM, Stefan Håkansson LK stefan.lk.hakans...@ericsson.com wrote: I think it should stop playing since the object srcObject references is gone. (It would work differently with createObjecURL + myVideoTag.src since that would only be a handle to an underlying resource) The object is not gone, it's neutered. That could mean e.g. that instead you'd get black and no sound. Kinda depends on how you define a neutered MediaStream to work. Right. I should've known. Thanks.
[Bug 22958] The parameter's value must be 'utf-8'
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22958 Robin Berjon ro...@w3.org changed: What|Removed |Added CC||public-webapps@w3.org, ||ro...@w3.org Component|HTML5 spec |Server-Sent Events (editor: ||Ian Hickson) Assignee|dave.n...@w3.org|i...@hixie.ch Product|HTML WG |WebAppsWG QA Contact|public-html-bugzi...@w3.org |public-webapps-bugzilla@w3. ||org --- Comment #2 from Robin Berjon ro...@w3.org --- Moving to WebApps -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 22958] The parameter's value must be 'utf-8'
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22958 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED CC||ann...@annevk.nl Resolution|--- |INVALID --- Comment #3 from Anne ann...@annevk.nl --- That requirement is a conformance requirement, not a processing requirement. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Extending createObjectUrl to MediaStream?
On Tue, Sep 3, 2013 at 6:31 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Sep 3, 2013 at 12:29 AM, Robert O'Callahan rob...@ocallahan.org wrote: What are your use-cases where they're not the same? More importantly, what are the use-cases where they cannot be made the same by the developer? E.g. embedding a widget for video or audio manipulation. The widget could be written by a third-party of sorts. The widget would not only have to be written by a third party, but actually hosted on their domain. And not just optionally, but for some reason the widget provider has decided not to allow the author to host it on their own domain. Sure, it could happen, but it seems somewhat far-fetched to me. On the other hand, allowing MediaStream graphs to span domains could have potentially far-reaching consequences. I don't see any need to rush into this. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * *
Re: Extending createObjectUrl to MediaStream?
On Tue, Sep 3, 2013 at 1:25 PM, Robert O'Callahan rob...@ocallahan.org wrote: The widget would not only have to be written by a third party, but actually hosted on their domain. And not just optionally, but for some reason the widget provider has decided not to allow the author to host it on their own domain. That's fairly common though, consider eg YouTube. Sure, it could happen, but it seems somewhat far-fetched to me. On the other hand, allowing MediaStream graphs to span domains could have potentially far-reaching consequences. I don't see any need to rush into this. It's not entirely clear to me what you mean by this. Are these concerns specific to MediaStream and not applicable to Blob? -- http://annevankesteren.nl/
Re: Extending createObjectUrl to MediaStream?
On Wed, Sep 4, 2013 at 12:31 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Sep 3, 2013 at 1:25 PM, Robert O'Callahan rob...@ocallahan.org wrote: The widget would not only have to be written by a third party, but actually hosted on their domain. And not just optionally, but for some reason the widget provider has decided not to allow the author to host it on their own domain. That's fairly common though, consider eg YouTube. Youtube hosts embedded players because they're playing Youtube's content, not because Youtube's widget is particularly special. If you just want an HTML5 video player app to wrap around your own content, you don't use Youtube and you host it yourself. Sure, it could happen, but it seems somewhat far-fetched to me. On the other hand, allowing MediaStream graphs to span domains could have potentially far-reaching consequences. I don't see any need to rush into this. It's not entirely clear to me what you mean by this. Are these concerns specific to MediaStream and not applicable to Blob? Yes. For example there are plans to enable some kind of private mode for WebRTC MediaStreams that protects stream contents from inspection by the page. I don't know exactly how this is going to work, but if we allow MediaStreams to span domains it may get more complicated. More concretely, in Gecko we have experimental code to pipe HTML media element output into MediaStreams, so we already tag MediaStream data with origin information, but it's implemented in such a way that getUserMedia from one domain would be restricted in another domain (the other domain could render it in a media element, but it would be treated as cross-origin and thus would taint canvases it's drawn into, for example). I think it may make sense to provide cross-origin MediaStream transfer at some point in the future, but I think we have more important things to work on first. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * *
Re: Extending createObjectUrl to MediaStream?
On Tue, Sep 3, 2013 at 2:01 PM, Robert O'Callahan rob...@ocallahan.org wrote: Yes. For example there are plans to enable some kind of private mode for WebRTC MediaStreams that protects stream contents from inspection by the page. I don't know exactly how this is going to work, but if we allow MediaStreams to span domains it may get more complicated. This scenario sounds very different from the one you outline next. More concretely, in Gecko we have experimental code to pipe HTML media element output into MediaStreams, so we already tag MediaStream data with origin information, but it's implemented in such a way that getUserMedia from one domain would be restricted in another domain (the other domain could render it in a media element, but it would be treated as cross-origin and thus would taint canvases it's drawn into, for example). It's not clear why if as a page I decide to share the MediaStream object I would not want all of that to be shared as I could share all of that regardless, it'd just require more hoops to jump through. I think it may make sense to provide cross-origin MediaStream transfer at some point in the future, but I think we have more important things to work on first. Again, what I'm trying to understand is why we have origin ties in the first place. So far no objects carry origin information in this regard. -- http://annevankesteren.nl/
[Bug 23138] New: Make type a ByteString
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23138 Bug ID: 23138 Summary: Make type a ByteString Classification: Unclassified Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: File API Assignee: a...@mozilla.com Reporter: a...@mozilla.com QA Contact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org Bug 23106 suggests that since 'type' attribute is used over HTTP and parsed like Content-Type, it should be a ByteString. -- You are receiving this mail because: You are on the CC list for the bug.
Re: File API: File's name property
Well, https://www.w3.org/Bugs/Public/show_bug.cgi?id=23138 is to make the 'type' attribute a ByteString. Is that your request here for the name attribute as well? It wouldn't be wise to restrict '/' or '\' or try to delve too deep into platform land BUT the FileSystem API introduces directory syntax which might make being lax a fly in the ointment for later. On Aug 29, 2013, at 10:48 AM, Anne van Kesteren wrote: As currently specified File's name property seems to be a code unit sequence. In zip archives the resource's path is a byte sequence. I don't really know what popular file systems do. Given that a File has to be transmitted over the wire now and then, including it's name property value, a code unit sequence seems like the wrong type. It would at least lead to information loss which I'm not sure is acceptable if we can prevent it (or at least make it more obvious that it is going on, by doing a transformation early on). We may also want to restrict \ and / to leave room for using these objects in path-based contexts later. -- http://annevankesteren.nl/
Re: File API: lacks model
Anne, This feedback is a bit vague. I think you should describe the underlying model for Blob/File so other specifications can more easily hook into it. E.g. if I want to represent a File object with a name /x/ and type /y/ there's not a clear way to do that right now. This also leads to issues such as [value space of properties] Why isn't there a clear way to do that now? https://www.w3.org/Bugs/Public/show_bug.cgi?id=23138 notwithstanding, you can either obtain a File from the underlying file system with a best guess type by the UA, OR create one with a constructor. What's missing exactly? E.g. A |blob| provides asynchronous access to a byte sequence. A blob has an associated |type| which is a MIME type. (Which could be a link to the variant of MIME type you use.) And then you build the API on top of this model. I treat http://mimesniff.spec.whatwg.org/ as relatively normative here. What am I missing? -- A*
[Bug 23140] New: Further Boundary Checking is Necessary on Slice Calls
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23140 Bug ID: 23140 Summary: Further Boundary Checking is Necessary on Slice Calls Classification: Unclassified Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: File API Assignee: a...@mozilla.com Reporter: a...@mozilla.com QA Contact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org https://bugzilla.mozilla.org/show_bug.cgi?id=906413 showcases a slice call on a Blob of size 4 of the sort: slice(0, Number.MAX_SIZE) on which on Fx returns a Blob of size 0, but only because of the 'long long' threshold being reached. This bug is to introduce further boundary checks on slice calls, disallowing a slice bigger than the original blob for example. -- You are receiving this mail because: You are on the CC list for the bug.
Re: File API: File's name property
On Tue, Sep 3, 2013 at 3:03 PM, Arun Ranganathan a...@mozilla.com wrote: Well, https://www.w3.org/Bugs/Public/show_bug.cgi?id=23138 is to make the 'type' attribute a ByteString. Is that your request here for the name attribute as well? I don't think you want those conversion semantics for name. I do think we want the value space for names across different systems to be equivalent, which if we support zip basically means bytes. This could mean accepting DOMString and then doing the conversion yourself through utf-8. However, it's not very clear to me how to do the conversion back in a way that minimizes information loss and works everywhere compatibly. For zip archives I ended up with rawPath (bytes) and path (bytes converted to a string using utf-8 and vice versa). Maybe we should use that model here too? It wouldn't be wise to restrict '/' or '\' or try to delve too deep into platform land BUT the FileSystem API introduces directory syntax which might make being lax a fly in the ointment for later. Right. Zip archives also have paths and it would be annoying if we ran into problems there. -- http://annevankesteren.nl/
Re: File API: File's name property
On Tue, Sep 3, 2013 at 9:03 AM, Arun Ranganathan a...@mozilla.com wrote: It wouldn't be wise to restrict '/' or '\' or try to delve too deep into platform land BUT the FileSystem API introduces directory syntax which might make being lax a fly in the ointment for later. I wouldn't object to restricting / if it'll make other APIs more sensible. Every platform I've used treats it as a separator. On Tue, Sep 3, 2013 at 10:17 AM, Anne van Kesteren ann...@annevk.nlwrote: I don't think you want those conversion semantics for name. I do think we want the value space for names across different systems to be equivalent, which if we support zip basically means bytes. I don't really understand the suggestion of using a ByteString for File.name. Can you explain how that wouldn't break https://zewt.org/~glenn/picker.html, if the user picks a file named 漢字.txt? -- Glenn Maynard
Re: File API: File's name property
On Tue, Sep 3, 2013 at 5:14 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Sep 3, 2013 at 10:17 AM, Anne van Kesteren ann...@annevk.nl wrote: I don't think you want those conversion semantics for name. I do think we want the value space for names across different systems to be equivalent, which if we support zip basically means bytes. I don't really understand the suggestion of using a ByteString for File.name. Can you explain how that wouldn't break https://zewt.org/~glenn/picker.html, if the user picks a file named 漢字.txt? ByteString doesn't work. A byte sequence might. If the platform does file names in Unicode it would be converted to bytes using utf-8. -- http://annevankesteren.nl/
Re: File API: lacks model
On Tue, Sep 3, 2013 at 3:07 PM, Arun Ranganathan a...@mozilla.com wrote: This feedback is a bit vague. Does http://the-pastry-box-project.net/anne-van-kesteren/2013-september-2/ help illustrate it a bit? I think you should describe the underlying model for Blob/File so other specifications can more easily hook into it. E.g. if I want to represent a File object with a name /x/ and type /y/ there's not a clear way to do that right now. This also leads to issues such as [value space of properties] Why isn't there a clear way to do that now? Say I define an API for zip archives and provide an API to get a File object out of a zip archive. I suppose I could define the relevant conversions to the attribute values, but it seems there should be an underlying abstract concept of a file that the File API reflects and operates on (and other APIs can operate on too). E.g. A |blob| provides asynchronous access to a byte sequence. A blob has an associated |type| which is a MIME type. (Which could be a link to the variant of MIME type you use.) And then you build the API on top of this model. I treat http://mimesniff.spec.whatwg.org/ as relatively normative here. What am I missing? Mostly that there's no abstract concept of a blob, just an API. (There's also that mimesniff treats types as a byte sequence, whereas your specification talks about it as both a byte sequence (ASCII-encoded string) and string (empty string). -- http://annevankesteren.nl/
Re: File API: File's name property
On Tue, Sep 3, 2013 at 5:54 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Sep 3, 2013 at 11:31 AM, Arun Ranganathan a...@mozilla.com wrote: And, restrict separators such as / and \. I thought we just agreed that \ is a platform-specific thing that File.name shouldn't restrict. / is a directory separator on just about every platform, but \ can appear in filenames on many systems. The problem is that once you put it through the URL parser it'll become /. And I suspect given directory APIs and such it'll go through that layer at some point. On Tue, Sep 3, 2013 at 11:28 AM, Anne van Kesteren ann...@annevk.nl wrote: ByteString doesn't work. A byte sequence might. If the platform does file names in Unicode it would be converted to bytes using utf-8. I don't know what API is being suggested that would keep File.name acting like a String, but also allow containing arbitrary bytes. I could imagine one (an object that holds bytes, stringifies assuming UTF-8 and converts from strings assuming UTF-8), but that's pretty ugly... Well, my suggestion was rawName and name (which would have loss of information), per the current zip archive API design. By the way, in the current ZIP URL proposal, where would a File be created? If you use XHR to access a file inside a ZIP URL then you'd just get a Blob, right? There's an API too. -- http://annevankesteren.nl/
Re: File API: File's name property
On Tue, Sep 3, 2013 at 5:31 PM, Arun Ranganathan a...@mozilla.com wrote: Which in fact is how I think we should do File.name. We'll stick to DOMString, but think it should specify a conversion to a byte sequence using utf-8. And, restrict separators such as / and \. That doesn't solve the problem I mentioned earlier for arbitrary file names coming out of zip archives. And then your data model is not bytes, but Unicode scalar values. We could of course accept information loss of some kind in the conversion process between zip archive resources and File objects and require developers to keep track of that if they care. -- http://annevankesteren.nl/
Re: File API: File's name property
On Sep 3, 2013, at 12:28 PM, Anne van Kesteren wrote: On Tue, Sep 3, 2013 at 5:14 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Sep 3, 2013 at 10:17 AM, Anne van Kesteren ann...@annevk.nl wrote: I don't think you want those conversion semantics for name. I do think we want the value space for names across different systems to be equivalent, which if we support zip basically means bytes. I don't really understand the suggestion of using a ByteString for File.name. Can you explain how that wouldn't break https://zewt.org/~glenn/picker.html, if the user picks a file named 漢字.txt? ByteString doesn't work. A byte sequence might. If the platform does file names in Unicode it would be converted to bytes using utf-8. Which in fact is how I think we should do File.name. We'll stick to DOMString, but think it should specify a conversion to a byte sequence using utf-8. And, restrict separators such as / and \. -- A*
Re: File API: File's name property
On Tue, Sep 3, 2013 at 11:31 AM, Arun Ranganathan a...@mozilla.com wrote: And, restrict separators such as / and \. I thought we just agreed that \ is a platform-specific thing that File.name shouldn't restrict. / is a directory separator on just about every platform, but \ can appear in filenames on many systems. On Tue, Sep 3, 2013 at 11:28 AM, Anne van Kesteren ann...@annevk.nlwrote: ByteString doesn't work. A byte sequence might. If the platform does file names in Unicode it would be converted to bytes using utf-8. I don't know what API is being suggested that would keep File.name acting like a String, but also allow containing arbitrary bytes. I could imagine one (an object that holds bytes, stringifies assuming UTF-8 and converts from strings assuming UTF-8), but that's pretty ugly... On Tue, Sep 3, 2013 at 11:42 AM, Anne van Kesteren ann...@annevk.nlwrote: That doesn't solve the problem I mentioned earlier for arbitrary file names coming out of zip archives. And then your data model is not bytes, but Unicode scalar values. We could of course accept information loss of some kind in the conversion process between zip archive resources and File objects and require developers to keep track of that if they care. If you want to retain the original bytes of the filename somewhere, it seems like it should go somewhere other than File.name. For example, a subclass of File, ZipFile, could contain a ByteString filenameBytes with the original filename. I wonder when you'd need that info, though. By the way, in the current ZIP URL proposal, where would a File be created? If you use XHR to access a file inside a ZIP URL then you'd just get a Blob, right? -- Glenn Maynard
Re: Fwd: [XHR] request error distinction: abort and error
The are no messages from Vitya in the public-webapps moderation queue, so I don't know what the problem might be. I've asked the W3C systems team to take a look. --Mike Anne van Kesteren ann...@annevk.nl, 2013-09-03 13:15 +0100: For some reason Vic9's emails do not reach lists.w3.org. Mike? -- Forwarded message -- Date: Mon, Sep 2, 2013 at 11:49 AM Subject: Re: [XHR] request error distinction: abort and error Hello, Anne van Kesteren mailing to you directly, because somehow my letters cannot reach w3.org http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0395.html it seems, that ESC key still can be used to abort XHR while page loading or with some special browsers configuration. Anyway, it would be nice to distinguish 3 situations: 1) network error; 2) cancellation by the user 3) document unloading in my product, i want to show the dialog with information about network error, but this dialog should not appear in other cases, as that will annoy the user. in my another product, i want to do retry in case of network error, but i should not do it in case of cancellation by the user. Thanks -- Michael[tm] Smith http://people.w3.org/mike
[Bug 23147] New: Describe File API Model
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23147 Bug ID: 23147 Summary: Describe File API Model Classification: Unclassified Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: File API Assignee: a...@mozilla.com Reporter: a...@mozilla.com QA Contact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org See http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0424.html This includes: 1. Property clarification and 2. MIME Type clarification -- You are receiving this mail because: You are on the CC list for the bug.
