Describe the bug
When submitting a file in a new datapackage in the editor, if the file is inaccessible on the local filesystem and a client error occurs, then the transfer fails, but the screen ends up locked and there are no options to recover to continue editing. This can result in loss of a lot of editing work if the package was not saved previously. The only recovery was to reload the window, losing all changes. This arose when testing for a user who was experiencing a different freeze (https://support.nceas.ucsb.edu/rt/Ticket/Display.html?id=32300)
To Reproduce
Steps to reproduce the behavior:
- Load https://test.arcticdata.io/catalog/submit when logged in
- Click on 'Add Files' button
- Choose a file that is visible in your drive but not readable by the browser. For me this was a Google Drive file which was not synced for offline use, but Google Drive was not mounted.
- The error manifests in the JS console as an error trying to calculate an md5 sum
- The error manifests visually as a frozen screen with a 'Waiting for 1 file to upload...' green button
Expected behavior
After getting the md5.js error, metacatui should recognize the file is not accessible, abort the file upload, reset the screen for further user input, and put up an explanatory error message about what went wrong. Something like Couldn't read that file from disk. Please verify it is accessible, and, if so, try again.
Screenshots
Screenshot of JS Console error:
Screenshot of frozen screen
Desktop (please complete the following information):
- OS: MacOS 15.7.3
- Browser: happened on FF, Chrome, Brave on multiple versions of each
- Version: FF 149.0, Brave 1.88.138
- MetacatUI: 2.36.2
Additional context
While this specific problem was a file reading problem locally, basically any error on the client side can result in this type of a frozen screen, and there are other examples in the issues (e.g., #467 #2752). We should have better error handling in general so that, once a browser is some sort of a waiting mode, there is a way to handle any oddball errors and give control back to the user. Leaving the user on an unclickable screen with no options but to reload is not viable.
Describe the bug
When submitting a file in a new datapackage in the editor, if the file is inaccessible on the local filesystem and a client error occurs, then the transfer fails, but the screen ends up locked and there are no options to recover to continue editing. This can result in loss of a lot of editing work if the package was not saved previously. The only recovery was to reload the window, losing all changes. This arose when testing for a user who was experiencing a different freeze (https://support.nceas.ucsb.edu/rt/Ticket/Display.html?id=32300)
To Reproduce
Steps to reproduce the behavior:
Expected behavior
After getting the md5.js error, metacatui should recognize the file is not accessible, abort the file upload, reset the screen for further user input, and put up an explanatory error message about what went wrong. Something like
Couldn't read that file from disk. Please verify it is accessible, and, if so, try again.Screenshots
Screenshot of JS Console error:
Screenshot of frozen screen
Desktop (please complete the following information):
Additional context
While this specific problem was a file reading problem locally, basically any error on the client side can result in this type of a frozen screen, and there are other examples in the issues (e.g., #467 #2752). We should have better error handling in general so that, once a browser is some sort of a
waitingmode, there is a way to handle any oddball errors and give control back to the user. Leaving the user on an unclickable screen with no options but to reload is not viable.