Details
-
Type: Improvement
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 2.0.0
-
Fix Version/s: 2.0.1
-
Component/s: ACE-Components
-
Labels:None
-
Environment:ACE fileEntry
-
Affects:Documentation (User Guide, Ref. Guide, etc.), Compatibility/Configuration
Description
After submitting the form, and uploading the file, the last selected file remains listed in the fileEntry component. This means that subsequent full form submits will re-upload the very same file. In many cases this is undesirable, and the field should be cleared after upload. In some limited circumstances, when validation has failed, applications may with for the corrected form submission to re-upload the file, so that everything can be managed all together, without having to write special cleanup code in the case of the form not being corrected, and the file having to be discarded on session expiry. In that case, it would be more user-friendly to maintain the selection.
So, whether we simply auto-clear the selection after upload, or introduce a property to control whether it is cleared on valid form submission, this needs to be addressed.
So, whether we simply auto-clear the selection after upload, or introduce a property to control whether it is cleared on valid form submission, this needs to be addressed.
Discovered an issue on IE 7 and 8, and possibly 6 and 9 but not sure. Not an issue in Firefox or Safari.
A first upload would work, but then a second upload would fail with a javascript exception. The next would succeed, and the next fail, and so on. The exception was about a node not supporting a property, and the code showed that is was where we set the progress div className.
Investigation of previous code changes showed that it was the auto-clearing code that uses innerHTML. Commenting it out made everything work. At first it looked like a race condition between the innerHTML assignment and the progress updates. But, it wasn't the progress updates, it was just the className assignment before we even do an upload, and it was too tick/tock in behaviour to be a race condition.
Investigation online found that IE has an incredibly odd behaviour with innerHTML, where some node types will become the correct dom nodes, and others will just become text nodes. Investigation of the affected nodes found that the input element was becomming an input element, but the div elements were becoming text nodes. The text nodes lacked the className property of their div counterparts.
I solved this by wrapping the input element in its own div, to sequester it from the progress divs, so that I could localise the innerHTML effects, and leave the progress divs unmolested.
Subversion 24235