=[xhr]
While debugging an intranet application using xmlHttpRequest recently, I got a message on the Firefox browser console: Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. This worries me, since many useful web browser features which are deprecated eventually disappear (e.g. CSS width specification in the col tag.) I have an application which makes many http requests to make multiple large updates to database work tables, finally running a single SQL xmlHttpRequest to copy all work table data to the main data tables after all updates are successful. 1. The volume and size of the data is too large to be sent by a single request 2. Each subsequent request cannot be submitted until the prior request is completed SUCCESSFULLY or the database will be corrupted 3. The final SQL acts as the commit for the whole shebang and has its own BEGIN TRANSACTION and COMMIT/ROLLBACK for safety In this case, synchronous xmlHttpRequests are not only NOT deprecated, they are ABSOLUTELY ESSENTIAL to provide reliable database updating for the end user, and reliability is what the end user most desires, in addition to IMMEDIATE FEEDBACK whether the update succeeded or not. Please do not deprecate synchronous xmlHttpRequests. They are needed in general and specifically needed for complex web applications. Also, unrelated, please bring back CSS width to the col tag. On very large data tables, this can reduce page downloads by megabytes, no matter how small you make your column class names.
Proposal for a credential management API.
TL;DR: Strawman spec and usecases at
https://github.com/mikewest/credentialmanagement
# Use Cases
User agents' password managers are a fragile and proprietary hodgepodge of
heuristics meant to detect and fill sign-in forms, password change forms,
etc.
We can do significantly better if we invite websites' explicit cooperation:
* Federated identity providers are nigh undetectable; I don't know of
any password managers that try to help users remember that they signed
into Stack Overflow with Twitter, not Google.
* Signing in without an explicit form submission (via XHR, WebSockets(!),
etc) is good for user experience, but difficult to reliably detect.
* Password change forms are less well-supported than they could be.
* Users are on their own when creating new accounts, faced either with a
list of identity providers they've mostly never heard of, or with the
challenge of coming up with a clever new password.
More background and exploration of native equivalents at
http://projects.mikewest.org/credentialmanagement/usecases/.
# Workarounds
HTML defines a number of `autocomplete` attributes which help explain
fields'
purpose to user agents. These make the common case of form submission more
reliably detectable, but are less helpful for XHR-based sign-in, and don't
address federated identity providers at all.
# Proposal:
The API I'm outlining here is intentionally small and simple: it does not
attempt to solve the general authentication problem in itself, but instead
provides an interface to user agents' existing password managers. That
functionality is valuable _now_, without significant effort on the part of
either browser vendors or website authors.
The API quite intentionally winks suggestively in the direction of an
authentication API that would, for instance, do an OAuth dance on behalf of
an
application, but that's not the immediate goal.
```
[NoInterfaceObject]
interface Credential {
readonly attribute DOMString id;
readonly attribute DOMString name;
readonly attribute DOMString avatarURL;
};
[Constructor(DOMString id, DOMString password, DOMString name, DOMString
avatarURL)]
interface LocalCredential : Credential {
readonly attribute DOMString password;
};
[Constructor(DOMString id, DOMString federation, DOMString name, DOMString
avatarURL)]
interface FederatedCredential : Credential {
readonly attribute DOMString federation;
};
partial interface Navigator {
readonly attribute CredentialsContainer credentials;
};
interface CredentialsContainer {
PromiseCredential? request(optional CredentialRequestOptions options);
Promiseany notifySignedIn(optional Credential credential);
Promiseany notifyFailedSignIn(optional Credential credential);
Promiseany notifySignedOut();
readonly attribute PendingCredential? pending;
};
```
A more detailed specification is up at
http://projects.mikewest.org/credentialmanagement/spec/.
# Example:
```
navigator.credentials.request({
'federations': [ 'https://federated-identity-provider.com/' ]
}).then(function(credential) {
if (!credential) {
// The user had no credentials, or elected not to provide one to this
site.
// Fall back to an existing login form.
}
var xhr = new XMLHttpRequest();
xhr.open(POST, https://example.com/loginEndpoint;);
var formData = new FormData();
formData.append(username, credential.id);
formData.append(password, credential.password);
xhr.onreadystatechange = function () {
if (this.readyState != this.DONE)
return;
var loginSucceeded = // Process response: if login succeeded, yay! If
not, boo!;
if (loginSucceeded) {
navigator.credentials.notifySignedIn(credential);
// Notify the user that signin succeeded! Do amazing, signed-in
things!
} else {
navigator.credentials.notifyFailedSignIn(credential);
// Notify the user that signin failed, and fall back to the usual
experience.
}
};
xhr.send(formData);
});
```
More examples at
http://projects.mikewest.org/credentialmanagement/spec/#introduction-examples
.
It's not clear to me that WebApps is the right venue from a process
perspective,
but this is almost certainly the right group of people to evaluate the
proposal.
Thanks in advance for your feedback, suggestions, and time. :)
-mike
--
Mike West mk...@google.com
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
[Bug 26478] New: Use DOMRect instead of ClientRect
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26478 Bug ID: 26478 Summary: Use DOMRect instead of ClientRect Product: WebAppsWG Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P2 Component: IME API Assignee: ko...@google.com Reporter: m_k...@ga2.so-net.ne.jp QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Current CSSOM spec uses DOMRect instead of ClientRect. But currnt draft of getCandidateWindowClientRect() uses ClientRect. Should IME API use DOMRect for this method? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26479] New: Platform does not support fullscreen, could fullscreenEnabled be false?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26479 Bug ID: 26479 Summary: Platform does not support fullscreen, could fullscreenEnabled be false? Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Fullscreen Assignee: ann...@annevk.nl Reporter: igso...@chromium.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org I wonder if it would be possible to change the spec so that fullscreenEnabled is false if the platform does not support full screen. This is the first time that I'm reviewing a standard, so I suspect that there is a reason why we can't do that (if so, I'd be grateful if you could explain, thanks!). The problem is that when the platform does not support fullscreen, fulscreenEnabled (http://fullscreen.spec.whatwg.org/#dom-document-fullscreenenabled) will return true but the request to enter fullscreen will fail with an error (http://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen) due to this condition: There is a previously-established user preference, security risk, or platform limitation. I think it would be better if fulscreenEnabled was false if we already know that the platform does not support full screen. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26480] New: Author style max-width/height can interfere with style
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26480
Bug ID: 26480
Summary: Author style max-width/height can interfere with style
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Fullscreen
Assignee: ann...@annevk.nl
Reporter: phil...@opera.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
http://fullscreen.spec.whatwg.org/#user-agent-level-style-sheet-defaults
!DOCTYPE html
meta name=viewport content=width=device-width
style
body {
background: pink;
margin: 0;
}
iframe {
border: 0;
height: 270px;
max-height: 50%;
width: 100%;
}
/style
iframe src=//www.youtube.com/embed/pg5iRruqcps/iframe
This is a minimized version of http://m.vk.com/video10345392_166569492
The author style sheet says max-height: 50% and since the user agent style
sheet doesn't say differently, in fullscreen the iframe fails to fill the
viewport.
Unless there's some case where this makes sense, min-width, min-height,
max-width and max-height should all be 100% in the UA style sheet.
It fixes the problem in the wild, at least.
--
You are receiving this mail because:
You are on the CC list for the bug.
Re: Proposal for a credential management API.
I like the idea of standardizing some of the interactions between password managers and web sites. I think we should strongly consider ways to integrate XSS mitigation. Hopefully before too long most people will be using a password manager. With most password managers, if there is a transient XSS on example.com, an attacker can use that XSS to trick the password manager into autofilling the password for example.com. This means, even though the XSS exposure might be temporary, the attackers can steal a large number of passwords, extending the attack window indefinitely. Some other reasons that XSS + password stealing is worse than plain XSS: 1) Passwords are often reused across web sites, so damage from password stealing spreads fast. 2) When the XSS is fully client-side, it is impossible to figure out which users had their passwords stolen. There is no way to reset their passwords and they may remain compromised indefinitely. 3) Sites often require re-entering passwords for privileged actions like changing email address or adding an SSH key. Adding password stealing to an XSS acts like privilege escalation, allowing actions that aren't possible with a plain XSS. Cookies have a very similar problem. If an XSS can grab the user's authentication cookies, the attacker can prolong their attack even after the XSS hole is closed. Microsoft addressed the problem in 2002 by adding the 'HttpOnly' flag for cookies in MSIE 6 SP 1. All browsers implement it now, to great effectiveness. At a past job, I fixed XSS for a top ten web site, and I can testify that it was incredibly valuable to know that attackers were not stealing our authentication cookies, because we set the HttpOnly flag.. There's no HttpOnly equivalent for password forms, but that's largely because password storage by the browser has never been specified. As long as we're trying to specify parts of that storage, I think we should strive for HttpOnly passwords. It's challenging because there are many different login techniques, but I think we can make it happen if web sites opt in. I'd say there are approximately three styles for login form submission: A) No JS. A form with some input type=text's that gets submitted when you click an input type=submit. B) Some JS. A form that gets submitted by JS calling form.submit(). C) All JS. A set of inputs whose contents are extracted by JS and POST'ed via XHR to the server. Clearly we can't make C safe against XSS. But I think a lot of web sites currently use A or B, or would be willing to use them in exchange for better security. Here's a rough idea: Define a new attribute 'httponly' for input elements. When a text input has httponly=true and the password manager saves the input value as a PendingCredential or a Credential, the password manager also stores an attribute httpOnly=true on the Credential. When the password manager autofills forms using a Credential with httpOnly=true, it should fill a placeholder value (possibly a numeric identifier for the Credential). When a form is submitted, the password manager should intercept the HTTP request and replace the placeholder value with the contents of the Credential. Note that this proposal doesn't break password strength meters implemented in JS, because it only addresses subsequent autofills of credentials. The first time a password is entered, e.g. during signup or change password, it is still fully accessible to JS. Thanks, Jacob
[Bug 26482] New: A fullscreen element ready check for an element...
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26482 Bug ID: 26482 Summary: A fullscreen element ready check for an element... Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Fullscreen Assignee: ann...@annevk.nl Reporter: phil...@opera.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org http://fullscreen.spec.whatwg.org/#api [[ A fullscreen element ready check for an element returns true if any of the following is true, and false otherwise ]] All of the conditions must be true. Also s/is/are/. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26483] New: fullscreenElements should be an ordered list
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26483 Bug ID: 26483 Summary: fullscreenElements should be an ordered list Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Fullscreen Assignee: ann...@annevk.nl Reporter: phil...@opera.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Nit: Sets are usually not ordered, so call it a list. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26484] New: Order of fullscreenchange events has reversed in requestFullscreen()
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26484 Bug ID: 26484 Summary: Order of fullscreenchange events has reversed in requestFullscreen() Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Fullscreen Assignee: ann...@annevk.nl Reporter: phil...@opera.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Previously the documents would notified from the top-level document and down, now it is the other order. The former order was sensible, so change append to prepend in While the last element in fullscreenElements is in a nested browsing context, append its browsing context container to fullscreenElements. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Proposal for a credential management API.
On Thu, Jul 31, 2014 at 8:19 AM, Jacob S Hoffman-Andrews j...@eff.org wrote: I'd say there are approximately three styles for login form submission: A) No JS. A form with some input type=text's that gets submitted when you click an input type=submit. B) Some JS. A form that gets submitted by JS calling form.submit(). C) All JS. A set of inputs whose contents are extracted by JS and POST'ed via XHR to the server. Clearly we can't make C safe against XSS. But I think a lot of web sites currently use A or B, or would be willing to use them in exchange for better security. I think we can make C work too. Here's a rough idea: Define a new attribute 'httponly' for input elements. And/or the password form could be annotated with an attribute that indicates for which domain an XHR should be allowed to submit the password to. And/or, you could have a submit-password CSP directive to indicate which domains passwords are allowed to be submitted to. In particular, if we are worried about XSS stealing passwords then we have to consider the possibility that XSS has inserted a form without any httponly attributes being used, right? When a text input has httponly=true and the password manager saves the input value as a PendingCredential or a Credential, the password manager also stores an attribute httpOnly=true on the Credential. When the password manager autofills forms using a Credential with httpOnly=true, it should fill a placeholder value (possibly a numeric identifier for the Credential). I was thinking the placeholder would be a base64url-encoded cryptographically-random nonce of sufficient length, so that the browser can replace the placeholders within arbitrary HTTP requests, regardless of (most) use of JS to mangle forms before submitting them, and without worrying about replacing the wrong part. When a form is submitted, the password manager should intercept the HTTP request and replace the placeholder value with the contents of the Credential. This would work with (C) too, would it not? It may be a good idea to add an attribute to XHR to trigger such replacement, so that the browser doesn't have to attempt substitution for every HTTP request. Web browsers with sandboxed child processes have the networking logic in the more-privileged parent process. The purpose of sandboxing is to protect against exploits in the child process. It would be useful for the process/privilege separation of sandboxing to be able to protect the values of passwords--even if it can't always protect the *use* of the passwords--even in the event of a compromised child process. The placeholder technique described by Jacob would facilitate such protection by giving the browser the ability to withhold passwords from the child (renderer) processes. Based on a quick read of Mike's proposal, this would require Mike's proposed API to change to pass around tokens that represent passwords, instead of the password values themselves. This would add complication, but it would be useful. This would probably not interact well with use of the WebCrypto API to encrypt the contents of input fields (passwords, credit card numbers, etc.) before submission. However, it seems reasonable to think that we could provide some way to integrate both things. One way would be to define a new API for declarative crypto operations, that allow the browser to do the substitution and then the crypto without the application's JS logic ever seeing it. Another way would be to provide a mechanism for isolating JS code from the DOM (possible reusing the worker infrastructure) so that some small part of the page's JS code can do the necessary transformations given the cleartext passwords, without leaking them; this seems hard though. Also note how this is pretty at odds with the idea (as I vaguely understand it) that ServiceWorkers should be able to do anything that the browser could do, unless the placeholder replacement was done for outgoing requests made by ServiceWorkers too. But, I think the protection of passwords and similar secrets is worthwhile enough to make exceptions and/or do extra work to resolve this conflict. BTW, Jacob's placeholder idea is similar to the ideas in: https://bugzilla.mozilla.org/show_bug.cgi?id=653132 and https://bugzilla.mozilla.org/show_bug.cgi?id=759860#c2 AFAICT, many security people at Mozilla thought it was a good idea, but nobody has tried to implement it in Firefox yet. I also think it is a good idea for some browser to try it out. Cheers, Brian
Re: Proposal for a credential management API.
On Thu, Jul 31, 2014 at 9:37 AM, Brian Smith br...@briansmith.org wrote: Web browsers with sandboxed child processes have the networking logic in the more-privileged parent process. The purpose of sandboxing is to protect against exploits in the child process. It would be useful for the process/privilege separation of sandboxing to be able to protect the values of passwords--even if it can't always protect the *use* of the passwords--even in the event of a compromised child process. By the way, I don't know if any browsers do this, but AFAICT HttpOnly cookies can be protected by such process separation in the same way, and we should ensure that ServiceWorkers is defined and implemented in a way that allows for such protection to (continue to) work. Cheers, Brian
Re: File API: reading a Blob
Aymeric, (Sorry for the delay; I was traveling for the last part of July.) On Jul 17, 2014, at 11:25 AM, Aymeric Vitte vitteayme...@gmail.com wrote: I don't get this, most reads inside browsers are about fetching, and fetching does increment a resource while it is loaded/displayed (image, video, crypto operations, etc) And it's question of the fetch API in this thread. XHR has the same issue, fortunately you can use XHR with Range, now I think this issue should stop propagating What I meant is that while I don’t think FileReader *or* FileReaderSync should be modified *at this stage* to include partial data, there is a workaround: 1. After obtaining the Blob or File, use .slice() to generate something like a mySlices[ ] array of e.g. 2K each slice. 2. Then use fileReader.readAsArrayBuffer(mySlices[0]…). This should be relatively efficient, and in fact can be cued to work at the completion of the last read, based on the final event being fired (or something similar — you get the idea). This might be similar to XHR range. This at least allows chunked reads. I agree that we need a stream-based API, but I don’t agree that it should be FileReader or FileReaderSync. That’s simply doing too much with too little. However, I think the next step would be to generate stream-based reads directly off the Blob, e.g. have something like myBlob.read(…) which returns a stream, which can be cued with API calls. 1. Decoding was an issue with *readAsText*. I suppose we could make that method alone be all or nothing. I don't see where the issue can be, it should behave like textdecoder and reinject the undecoded bytes to the next chunk, personnaly I find really useless to offer the 'text' methods in files/fetching APIs. The issue is that it isn’t possible to know the total number of decoded bytes is till the whole file is decoded, but of course we could only represent the bytes read thus far in progress events. Again, I don’t think FileReader or FileReaderSync are the right APIs for that. — A*
Re: Proposal for a credential management API.
On Thu, Jul 31, 2014 at 6:40 PM, Brian Smith br...@briansmith.org wrote: On Thu, Jul 31, 2014 at 9:37 AM, Brian Smith br...@briansmith.org wrote: Web browsers with sandboxed child processes have the networking logic in the more-privileged parent process. The purpose of sandboxing is to protect against exploits in the child process. It would be useful for the process/privilege separation of sandboxing to be able to protect the values of passwords--even if it can't always protect the *use* of the passwords--even in the event of a compromised child process. By the way, I don't know if any browsers do this, but AFAICT HttpOnly cookies can be protected by such process separation in the same way, and we should ensure that ServiceWorkers is defined and implemented in a way that allows for such protection to (continue to) work. Cookies (the non-HttpOnly kind) remain only exposed through document.cookie. Service workers, like XMLHttpRequest, have no access to cookies (including the non-HttpOnly kind) at all. -- http://annevankesteren.nl/
[Bug 26482] A fullscreen element ready check for an element...
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26482 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Anne ann...@annevk.nl --- https://github.com/whatwg/fullscreen/commit/538002226976b5ded393dff97432beed58867f9d -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26366] It's possible to go fullscreen with an element not in the document
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26366 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Anne ann...@annevk.nl --- New bugs for new issues I guess. Thanks all! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26484] Order of fullscreenchange events has reversed in requestFullscreen()
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26484 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Anne ann...@annevk.nl --- https://github.com/whatwg/fullscreen/commit/550dc005ba07cb098c761b115f891c4099218392 -- You are receiving this mail because: You are on the CC list for the bug.
Re: =[xhr]
On Tue, Jul 29, 2014 at 1:41 PM, nmork_consult...@cusa.canon.com wrote:
While debugging an intranet application using xmlHttpRequest recently, I got
a message on the Firefox browser console: Synchronous XMLHttpRequest on the
main thread is deprecated because of its detrimental effects to the end
user's experience.
This worries me, since many useful web browser features which are
deprecated eventually disappear (e.g. CSS width specification in the col
tag.)
This is definitely one of those things.
I have an application which makes many http requests to make multiple
large updates to database work tables, finally running a single SQL
xmlHttpRequest to copy all work table data to the main data tables after all
updates are successful.
1. The volume and size of the data is too large to be sent by a single
request
2. Each subsequent request cannot be submitted until the prior request is
completed SUCCESSFULLY or the database will be corrupted
3. The final SQL acts as the commit for the whole shebang and has its own
BEGIN TRANSACTION and COMMIT/ROLLBACK for safety
In this case, synchronous xmlHttpRequests are not only NOT deprecated, they
are ABSOLUTELY ESSENTIAL to provide reliable database updating for the end
user, and reliability is what the end user most desires, in addition to
IMMEDIATE FEEDBACK whether the update succeeded or not.
None of what you have described requires a synchronous XHR; it can all
be done with async XHR. You just wait to send the subsequent batches
of data until the listener from the previous one informs you that it
has succeeded. This is slightly more complicated than doing sync, but
no slower (and possible faster, if some of them can be done in
parallel), and just as reliable.
You get feedback exactly as quickly, modulo a millisecond or two of
accumulated delay from waiting for your listener to reach the top of
the message queue.
Your users get a vastly better experience out of it, too. Synchronous
XHR freezes the JS main thread until it returns, which means that any
interaction with the page is frozen too. (Users *might* be able to
scroll, if the browser is doing scrolling on another thread, but
that's about it.) Multiple large consecutive sync XHRs mean things
are frozen for a noticeable amount of time, especially if the network
is slow for whatever reason. Async XHR has none of this problem.
The last person on this list to assert that they absolutely needed
sync XHR didn't seem to understand what async XHR was. (They seemed
to think it was related to form submission; I don't know what you
think it is.) It's exactly identical to sync XHR, but rather than
freezing javascript until the response comes back, and giving you the
result as a return value, you just have to register an event listener
which'll get called when the response comes back, passing the result
as an argument to your callback. Spreading your logic across
callbacks is a little bit more complicated than doing sync code, but
it's a necessary part of tons of JS APIs already, so if you're not
familiar with how it works, you're gonna have to get familiar with it
really soon. ^_^
Also, unrelated, please bring back CSS width to the col tag. On very
large data tables, this can reduce page downloads by megabytes, no matter
how small you make your column class names.
Rather than putting classes on your tds, you can just use better
selectors. If you need to set the width of the cells in the second
column, you can just do `td:nth-child(2) { width: XXX; }`. Save
yourself a couple megabytes. ^_^
(This isn't *precisely* reliable, because it doesn't know about
rowspans/colspans, but you can often deal with that yourself.
Selectors level 4 adds an :nth-column() pseudo-class which is
identical to :nth-child(), but only works on table cells and knows
about rowspans and colspans, so it'll properly style everything in the
desired column no matter how the table is structured.)
~TJ
Re: File API: reading a Blob
Aymeric, (Sorry for the delay; I was traveling for the last part of July.) On Jul 17, 2014, at 11:25 AM, Aymeric Vitte vitteayme...@gmail.com wrote: I don't get this, most reads inside browsers are about fetching, and fetching does increment a resource while it is loaded/displayed (image, video, crypto operations, etc) And it's question of the fetch API in this thread. XHR has the same issue, fortunately you can use XHR with Range, now I think this issue should stop propagating What I meant is that while I don’t think FileReader *or* FileReaderSync should be modified *at this stage* to include partial data, there is a workaround: 1. After obtaining the Blob or File, use .slice() to generate something like a mySlices[ ] array of e.g. 2K each slice. 2. Then use fileReader.readAsArrayBuffer(mySlices[0]…). This should be relatively efficient, and in fact can be cued to work at the completion of the last read, based on the final event being fired (or something similar — you get the idea). This might be similar to XHR range. This at least allows chunked reads. I agree that we need a stream-based API, but I don’t agree that it should be FileReader or FileReaderSync. That’s simply doing too much with too little. However, I think the next step would be to generate stream-based reads directly off the Blob, e.g. have something like myBlob.read(…) which returns a stream, which can be cued with API calls. 1. Decoding was an issue with *readAsText*. I suppose we could make that method alone be all or nothing. I don't see where the issue can be, it should behave like textdecoder and reinject the undecoded bytes to the next chunk, personnaly I find really useless to offer the 'text' methods in files/fetching APIs. The issue is that it isn’t possible to know the total number of decoded bytes is till the whole file is decoded, but of course we could only represent the bytes read thus far in progress events. Again, I don’t think FileReader or FileReaderSync are the right APIs for that. — A*
[Bug 26483] fullscreenElements should be an ordered list
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26483 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24523] Spec should mention how fullscreen works on fragmented elements
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24523 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Anne ann...@annevk.nl --- https://github.com/whatwg/fullscreen/commit/3a29ee3ed4c987c252bb316e57277e80120192e5 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26479] Platform does not support fullscreen, could fullscreenEnabled be false?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26479 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Anne ann...@annevk.nl --- https://github.com/whatwg/fullscreen/commit/d35a070d443632d0071b49318e40092667ac9801 -- You are receiving this mail because: You are on the CC list for the bug.
