🐛 fix Windows bug with the admin file upload widget #21687
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
closes #21439
On Windows 10/Chrome (but maybe nowhere else?), attempting to drag a file into any of the drop targets in the admin panel resulted in flickering behavior, and generally dropping didn't actually trigger the upload.
I thought originally it was a problem with the size of the drop target, but it actually appears to be a rerender bug. In brief, handleDragging and handleStopDragging were firing repeatedly, and each fire triggered a rerender, that added or removed a div from the file upload widget.
I suspect some browser-specific difference in how drag events fire is to blame.
This PR moves the logic to change the classes applied to the div, rather than changing whether the div is present.
I have manually tested with Windows 10 in the users import, theme import, and content import widgets. Styles are preserved (although I think they could be improved, as the grey outline is really faint) and uploading now works consistently, instead of mostly triggering display of the raw file most of the time.