Page MenuHomePhabricator

text input history/autocomplete doesn't work with HTTPS under IE8-10
Closed, DeclinedPublic


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

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 ?

Version: 1.22.0
Severity: normal
See Also:



Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 2:10 AM
bzimport set Reference to bz53636.
bzimport added a subscriber: Unknown Object (MLST).

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.

says it's even specific to non-login forms. (huh wut ?)

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...
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.

Aklapper lowered the priority of this task from Low to Lowest.Jan 8 2015, 5:03 PM
Aklapper added a subscriber: Aklapper.

After a quick test, autocomplete seems to work fine on HTTPS on IE11 under Windows 8.1 (Desktop). It's not clear which versions of IE are being referred to here.

If I remember correctly this problem was at least with IE6, IE7 and IE8. I don't think i tested anything after that.

Anecdotal evidence on WP:VP/T suggests that it affects IE6 through IE10. IE11 is the first that apparently (according to @TTO) is working on this front.

TTO renamed this task from text input history/autocomplete doesn't work in IE + https to text input history/autocomplete doesn't work with HTTPS under IE6-10.Jun 13 2015, 12:14 AM
BBlack renamed this task from text input history/autocomplete doesn't work with HTTPS under IE6-10 to text input history/autocomplete doesn't work with HTTPS under IE8-10.Jun 13 2015, 2:55 PM
BBlack added a subscriber: BBlack.

I amended the title to the range IE8-10 because since late 2014 our HTTPS doesn't support IE6, therefore it's out of scope for any fix for this as well.

Declining this task because (a) It's been open for 3 years with no resolution and (b) IE8-10 are no longer "supported" browsers at all on the Microsoft end of things for nearly a year now ( ), so the rational response to any user complaint is to upgrade away from their vendor-unsupported browser to IE11 (or Chrome or FF, but not IE<11).