Last modified: 2013-10-22 13:59:00 UTC
We have reports that since the HTTPS enabling, the autocomplete history of (most notably) the editsummary is no longer working for IE users. This seems to be caused by Explorer that actively enforces this when pages are served over https and set cache headers to private/must-revalidate http://webmasters.stackexchange.com/questions/2160/form-autocompletion-not-working/2455#2455 http://stackoverflow.com/questions/364066/why-is-the-internet-explorer-autocomplete-feature-disabled-for-all-html-forms-on/364094#364094 We might want to check if autocomplete=on bypassed the default setting, and consider adding that to the fields where we want people to have this available ?
with 'autocomplete=on', I mean the attribute autocomplete set to be explicitly on.
I tested forcing autocomplete=on in script and it does not seem to solve this. This: http://blogs.msdn.com/b/ieinternals/archive/2009/09/11/troubleshooting-stored-login-problems-in-ie.aspx?PageIndex=3 says it's even specific to non-login forms. (huh wut ?) This: http://stackoverflow.com/questions/2240695/how-to-enable-autocomplete-when-using-internet-explorer-and-ssl suggests that removing no-cache from the cache-control headers fixes the problem. I wonder if max-age=0 (which is what we use) is interpreted by IE the same way as no-cache is, and if removing it would fix the problem I guess the above once again says a lot about Explorer engineering. (also, might this relate to the problem that some IE users have reported that their textarea contents have not been remembered if they go back in history ????)
DJ: Do you have time to write a patch for this?
I have explored messing with the cache control settings, but in IE 10, i cannot see an indication that the cache headers are affecting the outcome here. I did have to use a self signed certificate, so it might be that would break the logic. The headers that get sent on the editpage are OutputPage:sendCacheControl() inside the $this->mEnableClientCache block, specifically the # We do want clients to cache if they can, but they *must* check for updates I'm not sure what else to try. I had forms autocomplete to on, storing 'encrypted pages' on. Unless we have more hints I'm not sure what else could fix this. Other than disabling https.
I'm going to track this closely because I just asked this question at the pump... https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#AutoComplete_.E2.80.93_forms and my buddy, Jimbo, assured me it would be fixed soon. Well, that last part's not entirely true, but I do make a lot of edits that require the same edit summary, so this is a huge time bottleneck for me, and probably other contributors, as well. Please fix this soon, especially since bug 54626 has not yet been resolved.
This is not likely to be fixed. It was designed by Microsoft to specifically behave like that.
Proposing WONTFIX/INVALID as per comment 6. :-/
I think some other sites workaround this problem by implementing their own autocomplete using local storage/cookies. That is something we could consider as well of course.
