I have a very basic page that includes an <input type="file"> element. When I submit the form with a file selected, the server responds with a spreadsheet that gets opened in Excel (a "new window"). The implication of this behavior is that the initial screen and input element are still visible in IE. If I change the data on disk of the selected file and resubmit the form, Internet Explorer uploads the old contents a second time; my latest changes are not present in the content sent to the server. If I select the file via the input's Browse... button again, the new file contents are uploaded as expected. Firefox always sends the file's contents from disk which is the expected/desired behavior. It seems that Internet Explorer is doing some kind of caching of the uploaded file contents.
Is there any way to disable this "feature" and have IE pull the data from disk each time the form is submitted?
Is there any documentation available on this behavior? It's the first time I've encountered it and my searches have largely come up empty.
You can test out the conjecture with live demos posted on MS-Connect.
[...] the bug began with IE10, when FileList and Blob were implemented.
input.files is an html5 FileList of file/blob items.
To populate it, IE blobs each filepicker choice. They have a "snapshot state" (W3C term).
They're kept sync'd in case a selected file is updated before submission.
The bug is, IE fails to detect if the file is deleted, renamed, or replaced.
The filepicker snapshot goes stale in that circumstance.
Here is what happens when a file is selected in filepicker, then renamed and edited, prior to submitting the filepicker selection. Although a new file (with original filename) has been substituted in its place, the original file (now with different name and modified text) gets sent in the form. How is this possible? It is as though it was tracked via ntfs ObjectID, which is used with Distributed Link Tracking. Note carefully in this screenshot, the file name does not agree with the file content.
So, it's not a "caching" thing at all. It's a tracking bug.
Have you tried to use the autocomplete attribute for your input tag?
For example
<input type="text" autocomplete="off" />
should force value to be never be reused as stated in W3C docs:
autocomplete = on/ off/ default
- on - The on state indicates that the value is not particularly sensitive and the user can expect to be able to rely on his user
agent to remember values he has entered for that control.
- off - The off state indicates either that the control's input data is particularly sensitive (for example the activation code for a
nuclear weapon); or that it is a value that will never be reused
(for example a one-time-key for a bank login) and the user will
therefore have to explicitly enter the data each time, instead of
being able to rely on the UA to prefill the value for him; or that
the document provides its own autocomplete mechanism and does not
want the user agent to provide autocompletion values.
I had same issue in IE 10,11 . I am able to fix it using below code
var file = $('input[type="file"]');
file.removeAttr('value');
var cloneFile = file.clone();
file.parent().get(0).replaceChild(cloneFile.get(0), file.get(0));
If you are getting multiple object for file then use eq(-2) after selector like
$('input[type="file"]').eq(-2);
Comment me in case any issue .
I have not tried this myself, but you may want to try to use a dummy parameter to the form action and change its value just before every submit action. For example, if you have <form action="foo.php">, change this to <form action="foo.php?dummy=0">, and then use javascript to change the action part to become e.g. action="foo.php?dummy=1" and so on just before each submit.
