I am guessing: After the workflow change, the UI likely wants to revisit the object (now in the new state). I assume, it is using a (HTTP) redirect for this and uses a less than optimal url (the download rather than the view url).
At your place, I would verify whether the guess is correct -- looking at the "Z2.log" (= ZServer) log file. If so, I would try to find out where the redirect url is determined and check how to change it.
Note that the download url for "File" and "Image" likely is "<url_to_the_object>", while the view url likely is "<url_to_the_object>/view". For most object types, "<url_to_the object>" is also the view url.
portal_types/Link go to "Actions" tab , the "view" is missing from the view string. adding this fixes the issue
Note: this WF behavior also happened for documents and it also was missing the 'view'
It fixes the issue, however, I find it strange that something deep in the bowels of Zope caused the issue. Either the WF behavior had never been noticed (hard to believe) or this was a bug introduced somewhere along the line. Can't understand why.
Likely a not very relevant remark: it is not "something deep in the bowels of Zope". It is quite natural that a workflow wants to revisit the object once the object's state has been changed. Some objects have several "standard" views; e.g. for a file, you may want to view its content (or "download it") or its metadata (where the metadata view may contain a preview or even the complete content). For those objects, the wrong url may quite easily be used in some situations (e.g. for the workflow).