chahuistle
commented
5 years ago I found nothing on the forums or on StackOverflow, so I managed to make a minimal test that kind of replicates this issue. It seems that UI events and Vaadin's FileDownloader are not compatible. The proposed solution according to the documentation (https://vaadin.com/docs/v8/framework/articles/LettingTheUserDownloadAFile.html, I assumed this would also work with Vaadin 7) breaks if the content/name of the file to be downloaded is lazily generated.
The problem is when Vaadin UI code resides in the handleConnectorRequest or getFileDownloadResource methods, even if using polling and UI.access() to safely access the UI across threads.
My minimal test had one button attached to a FileDownloader. I had a counter and every time I clicked on the button, I would generate a file and show a notification (using Vaadin's UI). The counter would be incremented after every click. The content/name of the file was lazily generated (based on the value of the counter). The notification would display the counter.
No matter what I tried, there was a "delay" between the actual number of clicks and what was displayed on the notifications. Notifications would display, say, 2, at the third click. The content and name of the file were correct every time. This makes me to believe that UI code does not work properly in FileDownloaders. After all, FileDownloader is in the com.vaadin.server package.
So we split the process between validation and download in order to leave code related to FileDownloader free of accessing the UI.
We haven't been able to fully replicate this problem, but after a while of clicking around, testing, generating offer files, it seems as if the server replies to user interaction with some delay. What's worse is that the generated offer file seems to be "sticky", that is, the server keeps sending the same file.
For instance, one would try to generate an offer with invalid data, which would produce a notification, but the notification arrives only after the user clicks somewhere else.