You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Once the warnings are shown, modify the XLSForm. Do not select the file again after modifying it.
Click "Upload anyway".
What happens:
Chrome: I see the error message "Something went wrong: there was no response to your request."
Firefox: I see the error message "The XLSForm could not be converted: File is not a zip file"
Does this mean that Firefox is sending bad data?
Safari: No response received; spinner keeps spinning.
Note that this is different from #387, because here the file is not selected again.
What I expect:
I expect that Frontend will send the original XLSForm (before I modified it) or will show a more informative error message. Based on what I've read so far, I'm not sure we can easily identify this case in order to show an error message, but we should be able to immediately read the XLSForm into memory so that the browser doesn't try to access the file more than once.
I also encounter this behavior in Firefox and Safari (but not Chrome) when I do the following:
Select an XLSForm.
Modify the XLSForm without selecting it again.
Click the Upload button.
Again, I expect Frontend to send the original XLSForm or to show a more informative error message.
I realized that this issue affects file uploads generally, not just forms. I also encounter the issue on the form attachments page when I follow these steps:
Click "Upload files..."
Select a file.
Modify the file. Don't select it again.
Click "Looks good, proceed".
What happens:
Chrome: Sends the modified file.
Firefox: Seems to send the first N bytes of the modified file, where N is the size that the file was before modification. (This probably explains the Firefox error message above.)
Safari: Request does not complete.
In terms of a possible solution, we again have the option of reading the file into memory immediately after it is selected. However, I feel less sure about that solution for form attachments, since a form attachment can be large, and the user can select more than one at a time.
Another option is that we can read each file into memory before it is sent, using FileReader. It looks like the onerror handler will be called if the file has changed since it was selected:
Steps to reproduce:
What happens:
Note that this is different from #387, because here the file is not selected again.
What I expect:
I expect that Frontend will send the original XLSForm (before I modified it) or will show a more informative error message. Based on what I've read so far, I'm not sure we can easily identify this case in order to show an error message, but we should be able to immediately read the XLSForm into memory so that the browser doesn't try to access the file more than once.
I also encounter this behavior in Firefox and Safari (but not Chrome) when I do the following:
Again, I expect Frontend to send the original XLSForm or to show a more informative error message.
Background: https://stackoverflow.com/questions/61916331/re-uploading-a-file-with-ajax-after-it-was-changed-causes-neterr-upload-file-c
The text was updated successfully, but these errors were encountered: