[Bug 24479] New: [Streams] Bug: Unable to notify EOF after delivering the last element separately
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24479 Bug ID: 24479 Summary: [Streams] Bug: Unable to notify EOF after delivering the last element separately Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Streams API Assignee: tyosh...@google.com Reporter: tyosh...@google.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org After refactoring, the read() API is broken. We cannot notify EOF cleanly without setting fake undefined or null value to result.data if the last data is delivered to the reader without eof set. Needs fix. As we haven't received any objection against wait-then-sync-read approach like what I used in the first prototype [1], we can go back to that method again. [1] http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0481.html -- You are receiving this mail because: You are on the CC list for the bug.
Re: [HTML imports]: Imports and Content Security Policy
On 31.01.2014 06:43, Hajime Morrita wrote: Generally I prefer master-CSP model than the own CSP model due to its simplicity but I agree that unsafe-script kills the conciseness of Imports. To make inline scripts work with imports, we might want another CSP directive like safe-script, which allows parser-made script but doesn't allow dynamic ones. There is some room to talk what should be allowed as safe-script though. My gut feeling is A) script: Allowed, but B) inline event handlers: Not allowed. What is a safe script? What do you mean by parser-made script tags? We must be careful not to allow bypassing CSP with a simple XSS. Does this make sense?
[Bug 12607] Let authors control redirect behavior
https://www.w3.org/Bugs/Public/show_bug.cgi?id=12607 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #10 from Anne ann...@annevk.nl --- Unfortunately redirects have to be atomic. See bug 24375. -- You are receiving this mail because: You are on the CC list for the bug.
January 2014 edition of Standards for Web Applications on Mobile: current state and roadmap
Hi, I've just released the latest iteration of the quarterly overview of W3C technologies that increase the capabilities of Web apps with special relevance on mobile: http://www.w3.org/2014/01/mobile-web-app-state/ This new edition was developed in the Web and Mobile Interest Group, using a dedicated github repository: https://github.com/w3c-webmob/mobile-web-app-standards In particular, the data that is used to build the summary tables of the document is now managed via JSON files, hopefully making it easier to contribute to and re-use it. As always, the document highlight changes since the last edition (4 months ago). Dom
[XHR] XHR 1 / XHR 2
Hi, The TR draft says that the URL of the editors draft is: https://dvcs.w3.org/hg/xhr/xhr-1/raw-file/tip/Overview.html I believe it is meant to be: https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/Overview.html It sounds like the group decided to re-use the title XHR Level 1, while it covers the features that used to be in XHR Level 2. That's somewhat confusing (but it may be that it's the least confusing option?). In any case, the XMLHttpRequest2 shortname still points to the old XHR Level 2 draft: http://www.w3.org/TR/XMLHttpRequest2/ That should be fixed one way or the other. Thanks, Dom
Re: [File System APIs] If one is good, then two must be better?
On 1/31/14 10:44 AM, ext Ian Clelland wrote: Hi Art, For what it's worth, theFile API: Directories and System is also implemented (and supported) by Apache Cordova[1]. The implementation is essentially complete for mobile applications on Android, iOS and FireOS, with nearly-complete support on Blackberry and Windows Phone. While our plugin registry was counting downloads, it was the most-downloaded plugin for the platform by a wide margin, so I believe it is being used actively. Thanks for this information Ian! I don't know if Cordova should count as a browser implementation for the purposes of this WG, but we are implementing the APIs and making them available to (hybrid) web application developers. The group has some flexibility regarding the specifics of the interoperability criteria used to advance a spec along the Recommendation track, but we haven't talked about the criteria for these specs since they are still working drafts. That said, I believe all of WebApps' Candidate Recommendations have included a CR exit criteria along the lines of the spec will not advance to Proposed Recommendation until two or more independent implementations pass its test suite and our interpretation of independent implementations has been browsers (and not solutions like the Cordova APIs). -ArtB [1] http://cordova.apache.org/docs/en/3.3.0/cordova_file_file.md.html#File
[Bug 24481] New: Markup error around blob URL store
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24481 Bug ID: 24481 Summary: Markup error around blob URL store Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: File API Assignee: a...@mozilla.com Reporter: ann...@annevk.nl QA Contact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org http://dev.w3.org/2006/webapi/FileAPI/#BlobURLStore looks to have a markup error at the end of the paragraph. This could be a little clearer too. E.g. that it represents a mapping of identifier to Blob objects. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [HTML imports]: Imports and Content Security Policy
On Mon, Feb 3, 2014 at 2:23 AM, Frederik Braun fbr...@mozilla.com wrote: On 31.01.2014 06:43, Hajime Morrita wrote: Generally I prefer master-CSP model than the own CSP model due to its simplicity but I agree that unsafe-script kills the conciseness of Imports. To make inline scripts work with imports, we might want another CSP directive like safe-script, which allows parser-made script but doesn't allow dynamic ones. There is some room to talk what should be allowed as safe-script though. My gut feeling is A) script: Allowed, but B) inline event handlers: Not allowed. What is a safe script? What do you mean by parser-made script tags? We must be careful not to allow bypassing CSP with a simple XSS. Forget about safe. I tried to give some name to the notion. Parser-made script means the script tags and its contents that are written in HTML bytestream, not given by DOM mutation calls from scripts. As HTML Imports doesn't allow document.write(), it seems safe to assume that these scripts are statically given by the author, not an attacker. I agree that we should be careful here though. We need to take care of innerHTML somehow for example. Does this make sense? -- morrita
DOM PS: Disposition of Comments Doc Prepared
Hey folks, with the completion of the Last Call period for DOM Parsing and Serialization (last month on January 7th), I've collected all the technical comments that came in during that time in a disposition of comments document: https://dvcs.w3.org/hg/innerhtml/raw-file/tip/LC1_comments.htm Please check that these comments were recorded accurately, and that I haven't left anything out. No response yet means I haven't started working on the issue. I will begin working on addressing these comments shortly using the existing bugzilla bugs already filed. Thanks! -Travis
[Bug 24474] StorageQuota.requestPersistentQuota() should use [Clamp] on newQuota argument
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24474 kin...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from kin...@chromium.org --- Updated the draft: Promise requestPersistentQuota ([Clamp] unsigned long long newQuota); -- You are receiving this mail because: You are on the CC list for the bug.
