File upload - progress bar comes up only after file is completed uploaded

Problem: The progress dialog comes up only after file is completely uploaded to server.

We have a single click file upload with setImmediate(true).
We display a window with a progress bar to the user when StartedEvent gets fired.
We update progress bar by using the ProgressListener.
We observed that progress bard window is not displayed for the time it takes for the whole file to be uploaded and then progress bar window comes up with completed state.
User never sees a progress and it looks like nothing happens until the file is uploaded.

Just wondering if anyone had similar problem and are there any solutions?


Sadly, I cannot help, but we had a similar experience and just ended up not using the progress bar. If sometimes wouldn’t show up at all, and there were a couple of times when it almost looked right, but we couldn’t get it to be reliable enough to use it. Hope you get an answer that will help us all out…

Hi Prakash,
I’ve not had your problems, I’ve used progress bars without problems. Are you running the upload inside a thread? The progress bar uses a “timer” to poll for updates, so your code doing the upload needs to return upload status to the progress bar.

This is covered in the
Book of Vaadin
. When I used it, I followed this template and it worked fine, but granted I was not uploading files.

However, there is also a post noting there is a bug with uploading.
See here

Hope that helps.

I tried again and sure enough, it does seem to be working for me now. I don’t know if something was fixed in the meantime, but I suspect so since it was about a year ago that I last tried.

However, I did note that the com.vaadin.ui.Upload button looked good under Chrome, Safari and IE 9, but FF 12.0 (and Opera 11.64, too) showed the button being pushed aside by the gwt-FileUpload ‘file’ button (complete with a Browse button). After the upload, it looked normal again. I’ve also attached our code that does the file upload with progress bar in case that helps anybody out there.
12371.png (12 KB)

Thanks for the replies. Here is some additional information I wanted to share:

The progress dialog works fine in all environments except for one of our environments which uses https. We did some troubleshooting with netwrok sniffer and noticed the following behavior in HTTPS

  • Client does a multipart POST (immediately after user selects the file)

    • Client starts polling server after 800ms of the POST request
      08f1dc3d-7208-4512-9938-1ac3e41d744c0 PID300 pollForStarti

    • Server responds with
      [“change”,{“format”: “uidl”,“pid”: “PID300”},[“9”,{“id”: “PID300”,“immediate”:true,“notStarted”:true}]
      ]], “meta” : {}, “resources” : {}, “locales”:}]

  • Server responds back for initial POST with successful upload message

    download handled
  • Server fires the StartedEvent, bytes are written to the receiver, progress updates happens, file receiving completes. This processing happens very quickly within 7ms.

  • Client receives progressbar with completed message in response to the next polling request

So it appears that StartedEvent does not get fired until the whole file gets uploaded and the server responds for the initial multipart POST request for the file.

Our site is using HTTPS, too, and it works. Is the file at least reasonably large to note a progress bar working? Here, it seems like files that are less than half a meg often are transferred so quickly I wouldn’t see anything. It was very hard to test on my local dev PC because the upload was so fast. But I don’t really need a progress bar for actions that take less than a couple of seconds to complete anyway.

We are uploading files 3MB or higher and the upload takes a while, so the progress bar should come up. Interestingly we could not reproduce the problem in local SSL environments. Finally we ended up overriding

public void changeVariables(Object source, Map<String, Object> variables) 

of Upload class to get hold of first polling request from client (which happens around 800ms after the user selects file for upload) and show the progress window if it not already displayed. This seems to be working fine now. Progress window is now displayed and upadted.

Thanks for your input. Appreciate it.


Note that the GWT Uploader project also supports progress events with everything managed on the client side, so that’s another option you could consider:



I have a situation where I want to upload/ persist a csv formated text that is fetched from a text area. the csv contains string representation of Collection of contacts. the file contains a header raw with the contacts property name , email, phone … then starting next line the values continue so I want to read this file from the text area and validate the values against the correct format e.i. phone should follow “/^(1[ -]
)?((?\d{3})?[ -]
)?\d{3}-\d{4}$/” format… then if all good save this contacts to the database. I dont seem to find vaadins Upload helpfull, any thought on this would be appreciated

Here is an example to be copypasted in to the text area


With spring boot 1.5.9, Tomcat 8.5.23 and vaadin 8.3.0:

I’m experiencing the same problem that the progressbar gets shown after the upload is complete. But when tracking this down, the scenario is a bit different for me.

I don’t have the problem locally (dev setup): As soon as I set a polling interval (ui.setPollInterval), the progressbar gets updated during the upload. It thereby does not matter if I’m using the pull method or the push method with web sockets or the push method with LONG_POLLING. It just works (via http port 80).

Doing the very same with the Java variant of Elastic Beanstalk, I hit the problem: The progressbar does not refresh until the upload is complete. This happens again with any pull or push method. And again, it happens on port 80 (whereas this is a nginx proxy forwarding to Tomcat’s port 5000). In my case, TLS does not come into play at all. Instead, it’s rather very similar to this report:

After the upload has in fact started, the network view of Firefox reports a bunch of “notStarted” responses (during the upload) such as

for(;;);[{“syncId”: 305, “clientId”: 301, “changes” : [[“change”,{“pid”:“172”},[“41”,{“id”:“172”,“notStarted”:true}]
]], “state”:{}, “types”:{“172”:“41”}, “hierarchy”:{“172”:}, “rpc” : , “meta” : {}, “resources” : {}, “timings”:[3239, 0]

I reproduced the problem with recent Firefox and Chromium browser.