papegaaij commented on code in PR #1671:
URL: https://github.com/apache/wicket/pull/1671#discussion_r4324688331
##########
wicket-core/src/main/java/org/apache/wicket/markup/html/form/upload/resource/FileUploadToResourceField.js:
##########
@@ -19,10 +19,25 @@
'use strict';
- if (typeof(Wicket.FileUploadToResourceField) === 'object') {
+ if (typeof(Wicket.FileUploadToResourceField) === 'function') {
return;
}
+ // the keys of the errors, as the field knows them
+ const UPLOAD_TOO_LARGE = 'uploadTooLarge';
+ const UPLOAD_SINGLE_FILE_TOO_LARGE = 'uploadSingleFileTooLarge';
+ const UPLOAD_TOO_MANY_FILES = 'uploadTooManyFiles';
+ const UPLOAD_FAILED = 'uploadFailed';
+ const CONNECTION_LOST = 'uploadConnectionLost';
+ const UPLOAD_CANCELED = 'upload.canceled';
+
+ // the file lists of the fields, by field id: the text of the remove
buttons, by list id
+ const lists = {};
+
+ // the running uploads, by field id: the request, the files it sends and
the field it belongs
+ // to, which a new rendering of the field takes over
+ const uploads = {};
Review Comment:
Thanks, the replacement lifecycle and timeout handling address both original
findings correctly. There is one small edge-case regression in the new
registry, though.
Because `uploads` is a plain object, valid custom markup IDs such as
`constructor`, `toString`, and `hasOwnProperty` resolve to inherited
properties. The constructor treats these as existing uploads, and
`isUploading()` returns `true` before any request has started. Consequently,
`upload()` returns `false` without sending anything. I reproduced this against
both revisions: these IDs upload successfully in the previously reviewed
revision, but are refused in this revision. Default generated IDs are
unaffected.
A null-prototype object avoids these inherited entries without changing the
registry logic:
```suggestion
const uploads = Object.create(null);
```
Please also add a regression case showing that a field with one of these
custom IDs can start its first upload.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
