7.1.10 partially breaks FileDownloader

Vaadin 6 / 7 / 8
1

We have used the FileDownloader in the past in this way:

FileResource fr = new FileResource(outFile);
FileDownloader fd = new FileDownloader(fr);

                    final ConfirmDialog download= new ConfirmDialog("Herunterladen", destFile+" herunterladen");
                    UI.getCurrent().addWindow(download);
                    download.setWidth(30, Unit.EM);
                    download.setHeight(10, Unit.EM);
                    download.setCaption("PDF herunterladen");
                    download.getSaveButton().setCaption(Icon.download_alt+" "+destFile+" herunterladen");
                    fd.extend(download.getSaveButton());
                    download.getSaveButton().addClickListener(new ClickListener()
                        {
                            @Override
                            public void buttonClick(Button.ClickEvent event)
                            {
                                download.close();
                            }
                        });

Up to 7.1.9 this worked fine.
With 7.1.10 this only works for IE and no longer in Firefox 27.0

When we disable the download.close() then the download again works in Firefox,
but the side effect is, that the download dialog is remains open.

What is the correct way to have a (modal) dialog where we have a download button,
which onClick does start the download and closes the dialog?

2

Hmm, interesting. I’ll try to reproduce this.

3

Weird. I agree it doesn’t work on 7.1.10, but as far as I can see, this doesn’t work with Firefox on 7.1.9 either.

4

Hi,

I’m facing to the same problem.

How do I can close the modalpopup after the download ?
Thanks for your help

5

As the resource is attached to the connector it will be cleaned up when the connector is no longer in use, which in this case means when the button is removed. Testing the above on Chrome you will see that two requests to the server are made when clicking on the button:

  1. /run/APP/connector/0/6/dl/test.pdf (the download URL)
  2. /run/UIDL/ (the RPC request that will remove the button)

If you do the same with Firefox you will see

  1. /run/UIDL/ (the RPC request that will remove the button)
  2. /run/APP/connector/0/6/dl/test.pdf (the download URL)
    and an additional
    Feb 5, 2014 10:11:14 AM com.vaadin.server.ConnectorResourceHandler error WARNING: Ignoring connector request for no-existent connector 6 in root 0

Sounds like a classic race condition where the order of the request to the server matter. Whoever manages to lock the session first wins. If the UIDL connection comes first it will cleanup the resource before it has been served and the download fails. If it goes the other way around, everything will work.

6

I would be nice to have an “DownloadFinishedListener”.

fr.addDownloadFinishedListener(new DownloadFinishedListener() {
@Override
public void finished()
{
download.close();
}
});

7

Yes, that would be useful. We like to disable buttons on the start of a download and re-enable when complete to reduce clicking multiple downloads when it’s already in progress.

8

I thought I saw an issue reported saying FileDownloader extension does not work in Firefox if extending component on a subwindow (not the main window).

EDIT: Here we go:
#12244

Someone on our project had to replace FileDownloader extension with a Link component to work around the issue. It was working in Chrome but not in Firefox.

Thanks.

9

David - How do you know when the download is complete so you can re-enable the buttons?

10

This thread shows how to have a beforeDownload and afterDownload listener:

https://vaadin.com/forum#!/thread/3329519