Re: [whatwg] PSA: Chrome ignoring autocomplete=off for Autofill data
I believe so, but I'll double check and will email you off this thread. \i On Thu Nov 13 2014 at 11:06:37 PM Evan Stade est...@chromium.org wrote: That sounds like crbug.com/354257 which was fixed in March. Are you sure this is still a problem on newer versions of Chrome? On Thu, Nov 13, 2014 at 8:22 PM, Igor Minar imi...@google.com wrote: Are you going to properly fire changeinput events when autofill happens? The current autofill behavior is causing major headaches for application and framework developers and by ignoring autocomplete attribute you disable the only way developers can work around this bug. On angular we had to developer a special hack in an attempt to fix it, but it's far from ideal: https://github.com/angular/angular.js/issues/1460#issuecomment-33837127 The browser should let DOM know when autofill happens, so apps can treat user input and autofill as the same. Right now this is not the case and it sounds like you are going to make it only worse. \i On Thu Nov 13 2014 at 11:20:28 AM Evan Stade est...@chromium.org wrote: Hi, Chrome already ignores the prevalent autocomplete=off for password fields. We plan to ignore this tag for Autofill (addresses, credit cards) fields as well. autocomplete=off will still be respected for autocomplete data (e.g. past searches on crbug.com). We think this will break a very small number of sites that use autocomplete=off for legitimate reasons, e.g. they use the Google Maps Places Autocomplete API, and don't want Chrome trying to autofill in addition. But it will improve behavior for a much larger set of sites which use autocomplete=off for confused reasons as a part of, e.g., their checkout flow. We have found the prevalence of autocomplete=off in top sites' checkout forms to be quite high. Currently this new behavior is available behind a flag. We will soon be inverting the flag, so you have to opt into respecting autocomplete=off. I am curious what other browsers do around autocomplete=off, and if they respect it for address/user profile/credit card type data. Since there's no way to feature detect the browser's behavior, it would be convenient if all browsers agreed on the meaning/value of the attribute. -- Evan Stade
Re: [whatwg] relationship between labeled control and label for :active and :hover pseudos
On Nov 10, 2014, at 2:48 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/10/14, 5:31 PM, Florian Rivoal wrote: That said, the labeled control also maintains a list of references to the associated labels, so there is no particular difficulty involved in finding them. The difficulty is not finding them. The difficulty is efficiently updating hover state on the set of ancestors of all the nodes involved, some of which might still be in hover state when the control ceases to be. Indeed. It appears to me that this use case can be solved by the proposed :has() relational pseudo class as long as the author has structured so that the label is an ancestor of the input control it’s associated with: http://dev.w3.org/csswg/selectors4/#relational Given that, I don’t find it compelling to natively support this behavior in the browser. - R. Niwa
Re: [whatwg] Modifying the URL inside beforeunload event
On Thu, 13 Nov 2014, cowwoc wrote: In any case, the question seems to be whether history.replaceState() should be honored in beforeunload. Individually, each one is very well defined, but I don't see any discussion of what should happen when the two are used together. You just follow their algorithms. I don't understand what needs to be additionally specified. Can you elaborate? The beforeunload algorithm is here: https://html.spec.whatwg.org/#prompt-to-unload-a-document You get to step 4, then run script, which calls replaceState's algorithm: https://html.spec.whatwg.org/#dom-history-replacestate The session history entry gets updated. Then you return to beforeunload, starting at step 5. Eventually 'salvageable' gets set to false, and much later (when running the 'unload' algorithm) the doc gets discarded, without affecting the (mutated) session history entry. Are you saying that history.replaceState() should succeed or fail in this case? It should do what is specified. I'm not sure what succeed or fail would mean in this context. If you don't want the tabId to be shared, you shouldn't put it in the location bar in the first place -- removing it from the history is too late, because people copy and paste URLs from the location bar while the page is up. You could replaceState() during page load, but I would generally much more recommend sessionStorage for this purpose. Using sessionStorage alone wouldn't work because the goal of this exercise is to send the server a different authentication token per browser tab. I can store these tokens in the sessionStorage (in fact, I do) but that's not enough because the browser still needs to send the token to the server with each request. I hope this clarifies my dilemma. http://stackoverflow.com/a/26901232/14731 explains how my current implementation works. It's very lengthy and ugly so I'm more than happy to entertain alternatives. Personally the way I build apps these days is to just serve static files over HTTP, and do all the dynamic stuff over WebSocket, which would sidestep all these issues. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Modifying the URL inside beforeunload event
On 14/11/2014 6:39 PM, Ian Hickson wrote: On Thu, 13 Nov 2014, cowwoc wrote: In any case, the question seems to be whether history.replaceState() should be honored in beforeunload. Individually, each one is very well defined, but I don't see any discussion of what should happen when the two are used together. You just follow their algorithms. I don't understand what needs to be additionally specified. Can you elaborate? The beforeunload algorithm is here: https://html.spec.whatwg.org/#prompt-to-unload-a-document You get to step 4, then run script, which calls replaceState's algorithm: https://html.spec.whatwg.org/#dom-history-replacestate The session history entry gets updated. Then you return to beforeunload, starting at step 5. Eventually 'salvageable' gets set to false, and much later (when running the 'unload' algorithm) the doc gets discarded, without affecting the (mutated) session history entry. Are you saying that history.replaceState() should succeed or fail in this case? It should do what is specified. I'm not sure what succeed or fail would mean in this context. I appreciate your patience. Bare with me a little longer. I understood everything you wrote below up until the last sentence: the doc gets discarded, without affecting the (mutated) session history entry. I think you meant that the mutated session history entry gets kept, but to be certain I understood you correctly I'll rephrase the question: 1. Say we have two pages: OLD and NEW. 2. OLD contains a link to NEW. 3. I start off on OLD and click on the link. 4. The above logic runs (beforeunload event handler changes the URL using history.replaceState() from OLD to CHANGED) 5. The browser navigates to the NEW page. 6. Now... when the user examines the URL associated with the back-button, should he see OLD or CHANGED? Based on what you wrote above, I think the user should see CHANGED. Did I understand you correctly? Personally the way I build apps these days is to just serve static files over HTTP, and do all the dynamic stuff over WebSocket, which would sidestep all these issues. You mean you have a single-paged application and rewrite the underlying page asynchronously? How do you deal with needing to load different Javascript files per page? I guess you could simply load all the JS files all your pages would ever need, but I assume you do something a little more sophisticated. Thanks, Gili
Re: [whatwg] PSA: Chrome ignoring autocomplete=off for Autofill data
On 2014-11-14 19:10, Evan Stade wrote: The problem is that we don't think autocomplete=off is used judiciously. Could you make a compromise and respect autocomplete=off for only type=text, and ignore autocomplete=off for all other input types as you guys planned? And then look at how the web reacts to autocomplete=off being ignored for the other types before deciding on how to handle it for type=text? I know you can risk end up with bad web designers making all inputs of type=text instead of using the proper types like a good web designer would (or should). But for the end user that would be better than textarea hacks or other weird things to clear or ignore things or fully custom inputs. If the results (I'll assume the web will be watched to see how the reaction is to such changes right?) are positive and web designers actually do it correctly and do not try to hack or change the type of inputs to text en masse, then type=text would work fine forward as a input type for text that changes so frequently that any autofill or autocomplete would make no sense/be a waste of resources. Regards, Roger. -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] Modifying the URL inside beforeunload event
On 2014-11-15 02:08, cowwoc wrote: Personally the way I build apps these days is to just serve static files over HTTP, and do all the dynamic stuff over WebSocket, which would sidestep all these issues. You mean you have a single-paged application and rewrite the underlying page asynchronously? How do you deal with needing to load different Javascript files per page? I guess you could simply load all the JS files all your pages would ever need, but I assume you do something a little more sophisticated. Thanks, Gili The way you did it was with what I call a one shot cookie. A project I worked on I did a solution where sessionStorage was used to keep a token and a cookie was set via javascript and thus sent along with the request to the server which then tells the browser to delete the cookie in the reply. If the token needs updating then the server can send a one shot cookie to the browser, the javascript will then apply the needed changes to generate a new token (maybe a new salt or nonce is given) and then delete the cookie. Also, this form of cookie use does not fall under the cookie law in Europe AFAIK as it's part of a login mechanism so no need to show those annoying this site/page uses cookies box or warning. Using sessionStorage, and cookies to pass info to/from the server is my new preferred way as you can control how often the cookies are sent and to what part of the site. The solution is not as elegant as I'd like it though. One issue is you can't set the timeout for a cookie (sent from the server) to 0 or 1 sec or similar as the browser could delete the cookie before your javascript can get the data from it. In the other direction the issue is reliably deleting the cookie after it has been sent (sometimes one can use POST requests and avoid this part, but that may not always be practical). Looking at http://stackoverflow.com/questions/26556749/binding-tab-specific-data-to-an-http-get-request the solution you ended up with is very similar to what I ended up doing, I'm not aware of any better way to do this (yet). Regards, Roger. -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] Modifying the URL inside beforeunload event
On Fri, 14 Nov 2014, cowwoc wrote: 1. Say we have two pages: OLD and NEW. 2. OLD contains a link to NEW. 3. I start off on OLD and click on the link. 4. The above logic runs (beforeunload event handler changes the URL using history.replaceState() from OLD to CHANGED) 5. The browser navigates to the NEW page. 6. Now... when the user examines the URL associated with the back-button, should he see OLD or CHANGED? Unless I'm missing something, I'm pretty sure it should be CHANGED. I see no reason why it would make a difference whether the replaceState() call happens before or during the beforeunload handler; in either case, the history traversal hasn't happened yet. Personally the way I build apps these days is to just serve static files over HTTP, and do all the dynamic stuff over WebSocket, which would sidestep all these issues. You mean you have a single-paged application and rewrite the underlying page asynchronously? More or less. Google Calendar is an example of the kind of app I mean (though obviously that's not one I've written myself!). How do you deal with needing to load different Javascript files per page? You either load it all asynchronously, or you load it on-demand. Depends on your precise setup. Generally speaking I find that most of the logic ends up on the server; there's just not that much to do purely on the client side. Obviously that depends on how sophisticated the app is. If it's a game with crazy visuals, there's comparatively more client-side code. Similarly, if you have a rich-text editor with offline capabilities, there's obviously much more client-side code. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Modifying the URL inside beforeunload event
On 14/11/2014 8:56 PM, Roger Hågensen wrote: On 2014-11-15 02:08, cowwoc wrote: Personally the way I build apps these days is to just serve static files over HTTP, and do all the dynamic stuff over WebSocket, which would sidestep all these issues. You mean you have a single-paged application and rewrite the underlying page asynchronously? How do you deal with needing to load different Javascript files per page? I guess you could simply load all the JS files all your pages would ever need, but I assume you do something a little more sophisticated. Thanks, Gili The way you did it was with what I call a one shot cookie. A project I worked on I did a solution where sessionStorage was used to keep a token and a cookie was set via javascript and thus sent along with the request to the server which then tells the browser to delete the cookie in the reply. If the token needs updating then the server can send a one shot cookie to the browser, the javascript will then apply the needed changes to generate a new token (maybe a new salt or nonce is given) and then delete the cookie. Also, this form of cookie use does not fall under the cookie law in Europe AFAIK as it's part of a login mechanism so no need to show those annoying this site/page uses cookies box or warning. Using sessionStorage, and cookies to pass info to/from the server is my new preferred way as you can control how often the cookies are sent and to what part of the site. The solution is not as elegant as I'd like it though. One issue is you can't set the timeout for a cookie (sent from the server) to 0 or 1 sec or similar as the browser could delete the cookie before your javascript can get the data from it. In the other direction the issue is reliably deleting the cookie after it has been sent (sometimes one can use POST requests and avoid this part, but that may not always be practical). Looking at http://stackoverflow.com/questions/26556749/binding-tab-specific-data-to-an-http-get-request the solution you ended up with is very similar to what I ended up doing, I'm not aware of any better way to do this (yet). Regards, Roger. Hi Roger, Did you also use a URL parameter to indicate which cookie the server should look in? I think my solution is problematic in that I have to go through GetTabId.html on page load (which looks ugly) and even worse I recently discovered that View Source does not work because the browser re-sends the request without the tabId parameter (which I stripped to make the URL shareable). I feel like the ideal solution is within an arm's reach but I can't get there. Please describe your approach in more detail on http://stackoverflow.com/q/26556749/14731 so we can learn for each. Thanks, Gili
Re: [whatwg] Modifying the URL inside beforeunload event
On 2014-11-15 03:07, cowwoc wrote: On 14/11/2014 8:56 PM, Roger Hågensen wrote: Did you also use a URL parameter to indicate which cookie the server should look in? I think my solution is problematic in that I have to go through GetTabId.html on page load (which looks ugly) and even worse I recently discovered that View Source does not work because the browser re-sends the request without the tabId parameter (which I stripped to make the URL shareable). What I did was to use a one shot cookie, a request was only ever made by user interaction. The server basically get a token cookie and a id cookie. the server the responds and set the cookies for deletion. There is only ever one token and one id cookie sent, re-using the cookie names are not an issue. Now if each tab automatically makes requests then that is a different issue and in that case using POST instead of GET is advised, in that case you only ever have to send cookies from the server and not to the server. Please describe your approach in more detail on http://stackoverflow.com/q/26556749/14731 so we can learn for each. Don't have an account there, sorry. Regards, Roger. -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/
