[Bug 26479] Platform does not support fullscreen, could fullscreenEnabled be false?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26479 Anne changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Anne --- https://github.com/whatwg/fullscreen/commit/d35a070d443632d0071b49318e40092667ac9801 -- 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 changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Anne --- https://github.com/whatwg/fullscreen/commit/3a29ee3ed4c987c252bb316e57277e80120192e5 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26483] fullscreenElements should be an ordered list
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26483 Anne 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 26492] New: IndexedDB: add/put/update operations should define ordering of clone vs. keypath evaluation
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26492 Bug ID: 26492 Summary: IndexedDB: add/put/update operations should define ordering of clone vs. keypath evaluation Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Indexed Database API Assignee: dave.n...@w3.org Reporter: jsb...@google.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org We recently fixed a bug in Chromium, but it looks like it affects Firefox as well and is implicit in the web-platform-tests suite (key_invalid.htm) var store = db.createObjectStore('store', {keyPath: 'keypath'}); var values = ['string1', 'string2']; var obj = { get keypath() { return values.shift(); } }; store.put(obj); store.openCursor().onsuccess = function(e) { console.log('key is: ' + e.target.result.key); console.log('value has: ' + JSON.stringify(e.target.result.value.keypath)); }; In FF33 the key is 'string1' and the value has 'string2'. Having these out of sync seems like a violation of the intent of the spec, although the letter of the spec does imply tests before cloning. In Chromium (circa 38) we clone, then evaluate the keypaths, so the result is 'string1' / 'string1'. This manifests in the key_invalid.htm test since it provides invalid key values such as function(){}. In Chromium we return DataCloneError since we clone before evaluating, whereas the test looks for DataError since it assumes evaluation before cloning. -- You are receiving this mail because: You are on the CC list for the bug.
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 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: =[xhr]
On Tue, Jul 29, 2014 at 1:41 PM, 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 > 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 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 s, 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
[Bug 26484] Order of fullscreenchange events has reversed in requestFullscreen()
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26484 Anne changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Anne --- https://github.com/whatwg/fullscreen/commit/550dc005ba07cb098c761b115f891c4099218392 -- 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 changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Anne --- 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 26482] "A fullscreen element ready check for an element..."
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26482 Anne changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Anne --- https://github.com/whatwg/fullscreen/commit/538002226976b5ded393dff97432beed58867f9d -- 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 6:40 PM, Brian Smith wrote: > On Thu, Jul 31, 2014 at 9:37 AM, Brian Smith 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/
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 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 9:37 AM, Brian Smith 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: Proposal for a credential management API.
On Thu, Jul 31, 2014 at 8:19 AM, Jacob S Hoffman-Andrews wrote: > I'd say there are approximately three styles for login form submission: > A) No JS. A with some 's that gets submitted when > you click an . > B) Some JS. A that gets submitted by JS calling form.submit(). > C) All JS. A set of 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
[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.
[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 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.
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 with some 's that gets submitted when you click an . B) Some JS. A that gets submitted by JS calling form.submit(). C) All JS. A set of 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 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 body { background: pink; margin: 0; } iframe { border: 0; height: 270px; max-height: 50%; width: 100%; } 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.
[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 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.
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 { Promise request(optional CredentialRequestOptions options); Promise notifySignedIn(optional Credential credential); Promise notifyFailedSignIn(optional Credential credential); Promise 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 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.)
=[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 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 tag. On very large data tables, this can reduce page downloads by megabytes, no matter how small you make your column class names.