[Bug 24573] New: Clarify non-null Blob
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24573 Bug ID: 24573 Summary: Clarify non-null Blob Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: File API Assignee: a...@mozilla.com Reporter: sim...@opera.com QA Contact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org http://dev.w3.org/2006/webapi/FileAPI/#validBlob It's not clear to me what non-null Blob means. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24573] Clarify non-null Blob
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24573 Simon Pieters sim...@opera.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Simon Pieters sim...@opera.com --- *** This bug has been marked as a duplicate of bug 24469 *** -- You are receiving this mail because: You are on the CC list for the bug.
Re: Update on Streams API Status
On Fri, Feb 7, 2014 at 5:31 AM, Feras Moussa feras.mou...@hotmail.com wrote: In addition to the base Stream spec, the remaining platform-specific pieces which do not fit into the shared-base spec will live in an independent spec. This includes things such as support in other APIs (XHR, MediaStreaming, etc) or DOM specific scenarios - (createObjectURL()). The current W3C Streams API will focus on this aspect of the API surface, while leaving the core functionality to be defined in the base spec. Once we've reorganized the components as defined above, we will share out further details for locations of the specs as well as solicit review. Sounds great, thanks guys! As for createObjectURL(), it has not been a great success for Blob objects. I'm not really sure we should widen that experiment. At least not until the way they are supposed to be implemented for Blob objects has actually been done in practice. -- http://annevankesteren.nl/
[Bug 24576] New: Calling URL.createObjectURL() on a closed Blob
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24576 Bug ID: 24576 Summary: Calling URL.createObjectURL() on a closed Blob Product: WebAppsWG Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P2 Component: File API Assignee: a...@mozilla.com Reporter: s...@opera.com QA Contact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org What is the required behavior for var blob = new Blob(); blob.close(); URL.createObjectURL(blob); Failure (what exception, if so?), or observably equal to var blob = new Blob(); URL.createObjectURL(blob); http://dev.w3.org/2006/webapi/FileAPI/#close-method says ..once close() has been called on a Blob, that Blob cannot be used again. unclear what that means exactly in this context. A clarification would be appreciated. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24577] New: [Custom]: Need adopted callback
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24577 Bug ID: 24577 Summary: [Custom]: Need adopted callback Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: ann...@annevk.nl QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14968 See bug 20567 comment 69. We should have a callback for adoption so you can deal with moving to a new document and prevent leaking an entire global. The callback should take the old and new document as arguments. See bug 24570 for the equivalent bug on cloning. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24578] New: [Custom]: define registry primitive
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24578 Bug ID: 24578 Summary: [Custom]: define registry primitive Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: ann...@annevk.nl QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14968 See bug 20567 comment 69. Exposing the registry would make it easier for components to be supported across documents and globals. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24579] New: [Custom]: make callbacks more explicit
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24579 Bug ID: 24579 Summary: [Custom]: make callbacks more explicit Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: ann...@annevk.nl QA Contact: public-webapps-bugzi...@w3.org CC: c...@mcc.id.au, m...@w3.org, public-webapps@w3.org Blocks: 14968 Any time a script calls a method, reads or sets a property that is implemented by the user agent, the following actions must occur: This needs to become part of the actual algorithms such as innerHTML, cloneNode(), etc. The easiest way to do that is tying it to IDL I think just as is done in the Chrome implementation. I recommend working with heycam on doing that per my outline in http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0142.html as that makes it much more explicit when everything happens relative to each other. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24557] [Shadow]: The definition of focus navigation is misleading.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24557 Hayato Ito hay...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hayato Ito hay...@chromium.org --- Fixed in https://github.com/w3c/webcomponents/commit/ec0237d249c999a3046985a375cfb44e4926c50b -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 15417] Redirects and the base URL
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15417 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Anne ann...@annevk.nl --- That doesn't seem like sufficient reason, but it's also out of scope of this bug. https://github.com/whatwg/xhr/commit/0c9670185b79c255211881e086e05e7a99e65f06 -- You are receiving this mail because: You are on the CC list for the bug.
Officially deprecating main-thread synchronous XHR?
Hi all, I wonder what people think of if we started to rather aggressively deprecate the horrible API main-thread sync XHR? Currently its usage is still way too high (up to 2% based on telemetry data), but if all the browsers warned about use of deprecated feature, we might be able to get its usage down. And at least we'd improve responsiveness of those websites which stop using sync XHR because of the warning. -Olli
RE: Officially deprecating main-thread synchronous XHR?
From: Olli Pettay olli.pet...@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.
Re: Officially deprecating main-thread synchronous XHR?
On 2/7/14 5:56 PM, Domenic Denicola wrote: I think this is a great point that makes such an effort worthwhile even if it ends up not leading to euthanizing sync XHR. I am all for it. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla
Re: Officially deprecating main-thread synchronous XHR?
On Fri, Feb 7, 2014 at 6:18 PM, Jonas Sicking jo...@sicking.cc wrote: 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). For what it's worth, was done when Olli brought this up in #whatwg: http://xhr.spec.whatwg.org/#sync-warning -- http://annevankesteren.nl/
Re: Officially deprecating main-thread synchronous XHR?
What about developers who are sending requests as the page is unloading? My understanding is that sync requests are required. Is this not the case? On Friday, February 7, 2014, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Feb 7, 2014 at 6:18 PM, Jonas Sicking jo...@sicking.cc wrote: 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). For what it's worth, was done when Olli brought this up in #whatwg: http://xhr.spec.whatwg.org/#sync-warning -- http://annevankesteren.nl/
RE: Officially deprecating main-thread synchronous XHR?
As I understand it, that is one of the scenarios covered by the recently proposed Beacon API: http://www.w3.org/TR/beacon/ Sent from my Windows Phone From: Scott González Sent: 2/7/2014 9:33 AM To: Anne van Kesteren Cc: Jonas Sicking; Domenic Denicola; o...@pettay.fi; public-webapps@w3.org Subject: Re: Officially deprecating main-thread synchronous XHR? What about developers who are sending requests as the page is unloading? My understanding is that sync requests are required. Is this not the case? On Friday, February 7, 2014, Anne van Kesteren ann...@annevk.nlmailto:ann...@annevk.nl wrote: On Fri, Feb 7, 2014 at 6:18 PM, Jonas Sicking jo...@sicking.cc wrote: 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). For what it's worth, was done when Olli brought this up in #whatwg: http://xhr.spec.whatwg.org/#sync-warning -- http://annevankesteren.nl/
Re: Officially deprecating main-thread synchronous XHR?
On 2/7/14 12:32 PM, Scott González wrote: What about developers who are sending requests as the page is unloading? Does Beacon address their use cases? If not, what are the use cases? -Boris
Re: Officially deprecating main-thread synchronous XHR?
On 02/07/2014 07:32 PM, Scott González wrote: What about developers who are sending requests as the page is unloading? My understanding is that sync requests are required. Is this not the case? We need sendBeacon asap, and browsers could start warn first when sync XHR is used outside unload event listeners. On Friday, February 7, 2014, Anne van Kesteren ann...@annevk.nl mailto:ann...@annevk.nl wrote: On Fri, Feb 7, 2014 at 6:18 PM, Jonas Sicking jo...@sicking.cc wrote: 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). For what it's worth, was done when Olli brought this up in #whatwg: http://xhr.spec.whatwg.org/#sync-warning -- http://annevankesteren.nl/
Re: [File System APIs] If one is good, then two must be better?
On 1/31/14 10:21 AM, ext Arthur Barstow wrote: * Do we want to continue both efforts (and thus reflect this in the charter update)? Given the feedback on this thread, I don't think there is consensus to only focus on one API so I added the Mozilla FileSystem API spec to the set of File interaction APIs in the [Draft] Charter (see changeset [CS]). -ArtB [Draft] http://afbarstow.github.io/WebApps/charter.html [CS] https://github.com/AFBarstow/WebApps/commit/d4c312595a120758ca076851b364503287d2aa8e
Re: Officially deprecating main-thread synchronous XHR?
As a side-note, it may be interesting to warn also that synchronous XHR has different semantics between browsers so is not a good choice anyway. Cheers, David On 2/7/14 6:18 PM, Jonas Sicking wrote: 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? / Jonas -- David Rajchenbach-Teller, PhD Performance Team, Mozilla
[Bug 24583] New: [imports]: failed fetch should result null document in import list
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24583 Bug ID: 24583 Summary: [imports]: failed fetch should result null document in import list Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: morr...@google.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 20683 Current import fetching algorithm registers empty document to the import list when the fetch failed. It should result null document. It doesn't make any observable reference. It just clarifies the intention. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 21650] Require that XHR is available in workers
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21650 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Anne ann...@annevk.nl --- https://github.com/whatwg/xhr/commit/4d307f0a00301fbd147ed78f37428694b14cde08 -- You are receiving this mail because: You are on the CC list for the bug.
RE: Officially deprecating main-thread synchronous XHR?
On Feb 7, 2014 8:57 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Olli Pettay olli.pet...@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? / Jonas
Re: Officially deprecating main-thread synchronous XHR?
On Feb 7, 2014, at 9:32 AM, Scott González scott.gonza...@gmail.com wrote: What about developers who are sending requests as the page is unloading? My understanding is that sync requests are required. Is this not the case? Besides the proposed Beacon API, if you don't need to do a POST then you can use an img element created at unload time - a load initiated this way will generally survive unloading the page. - Maciej On Friday, February 7, 2014, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Feb 7, 2014 at 6:18 PM, Jonas Sicking jo...@sicking.cc wrote: 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). For what it's worth, was done when Olli brought this up in #whatwg: http://xhr.spec.whatwg.org/#sync-warning -- http://annevankesteren.nl/
Re: Officially deprecating main-thread synchronous XHR?
On Feb 7, 2014, at 9:18 AM, Jonas Sicking jo...@sicking.cc wrote: On Feb 7, 2014 8:57 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Olli Pettay olli.pet...@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
[Bug 24586] New: Remove FileList
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24586 Bug ID: 24586 Summary: Remove FileList Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: File API Assignee: a...@mozilla.com Reporter: jo...@sicking.cc QA Contact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org Depends on: 23682 Bug 23682 seems to be solving the issue of how to return a JS-array of Foo objects rather than having to introduce new FooList types. This means that we can remove FileList. This should be a backwards compatible change spec-wise. Some implementations supports the syntax myfilelist.item(5) which would be lost in this change. But given that no one has asked for the .item function to be brought back, hopefully this should be fine. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Officially deprecating main-thread synchronous XHR?
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 m...@apple.com wrote: On Feb 7, 2014, at 9:18 AM, Jonas Sicking jo...@sicking.cc wrote: On Feb 7, 2014 8:57 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Olli Pettay olli.pet...@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
Re: Officially deprecating main-thread synchronous XHR?
On 02/08/2014 03:19 AM, James Greene wrote: 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. Doesn't sound like a case where we should allow the horrible sync XHR to run. If really needed, we can add something to clipboard API to let it deal with asynchronous loading. 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 m...@apple.com mailto:m...@apple.com wrote: On Feb 7, 2014, at 9:18 AM, Jonas Sicking jo...@sicking.cc mailto:jo...@sicking.cc wrote: On Feb 7, 2014 8:57 AM, Domenic Denicola dome...@domenicdenicola.com mailto:dome...@domenicdenicola.com wrote: From: Olli Pettay olli.pet...@helsinki.fi mailto:olli.pet...@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
