Update to DotVVM 2.5.1

We’ve just released DotVVM 2.5.1 – a new version bringing an important fix. If you are using DotVVM 2.5, please upgrade to 2.5.1.

Summary

In DotVVM 2.5, if you return a file as a response to postback or a static command (either using Context.ReturnFile or Context.Redirect), subsequent postbacks on the page are disabled and the user is not able to perform any action on the page.

How to fix the issue

Upgrade to DotVVM 2.5.1 where the issue is fixed.

Background

In DotVVM 2.5, we’ve done several improvements to the postback and static command pipeline. One important thing we tried to address was the behavior of redirects. When the page receives a redirect response, the browser starts loading the new page, however the current page is still working for a while. If the server responds slowly, the page can still work for a couple of seconds. The user can click on buttons which trigger another postbacks or static commands (which can be processed faster than loading the new page so they are applied on the current page as well).

It is a natural behavior of web, and all in all, it is not a significant issue. However, it can lead to some confusion – the postbacks made during the redirect may fail because of invalid state of the viewmodel (when you send the user away using a redirect, you don’t commonly expect that the viewmodel will be used again). That’s why we thought it would be a nice thing to disable postbacks once we get the redirect response – we wanted to make sure that the redirect is the last thing that will happen on the page.

In SPA (which basically doesn’t unload the page), we enable the postbacks once the SPA navigation is completed. In normal apps we just disabled the postbacks because the page will be unloaded eventually.

What we didn’t realize is the fact that if you send a file as a response (either by using our own function ReturnFile, or by redirecting on it), the page is not unloaded at all – the browser just starts to download the file but the page remains active. What happens is that once you send the user a file, the page becomes unusable and the user cannot make another postback. Our UI tests unfortunately didn’t cover this scenario, so this issue unfortunately got into the production release.

There is even no browser event that we could hook on to detect that the file download has started. There are some obscure ways how to detect that the file download started (sending a cookie with the file and observing it on the client-side using a timer), but we didn’t want to go that way. That’s why we decided to remove the postback disabling feature.

The feature is still present in SPAs because there is an event that tell us when to enable the postbacks, so when you redirect or navigate to a new page, it is not possible to start a new postback. Also, we have made sure that the long-running postbacks from the previous page are not applied to the new page.

We will be porting this fix into DotVVM 3.0 shortly. We have to implement it in a different way as the JavaScript part of the framework was heavily refactored (and luckily, it fixes additional issues we had in the postback pipeline).