As i’ve found from years of maintaining download.js, there simply is no way to tell from JS (or likely in general, see below) what a user chooses to do with the download Open/Save dialog. It’s a common feature request, and i’ve looked into it repeatedly over the years. I can say with confidence that it’s impossible; I’ll joyfully pay 10 times this bounty if someone can demo a mechanical way to determine the post-prompt user action on any file!
Further, it’s not really just a matter of JS rules, the problem is complicated by the way browsers download and prompt such files. This means that even servers can’t always tell what happened. There might be some specific work-arounds for a few specific cases, but they are not pretty or simple.
You could force your users to “re-upload” a downloaded file with an <input type=file> to validate it, but that’s cumbersome at best, and the local file browse dialog could be alarming to some. It’s the only sure-fire method to ensure a download, but for non-sensitive applications its very draconian, and it won’t work on some “mobile” platforms that lack file support.
You might also try watching from the server side, pushing a message to the client that the file was hit on the server. The problem here is that downloads start downloading as soon as the Open/Save dialog appears, though invisibly in the background. That’s why if you wait a few moments to “accept” a large file, it seems to download quickly at first. From the server’s perspective, the activity is the same regardless of what the user does.
For a huge file, you could probably detect that the whole file was not transferred, which implies the user clicked “cancel”, but it’s a complicated syncing procedure pushing the status from backend to client. It would require a lot of custom programming with sockets, PHP message passing, EventSource, etc for little gain. It’s also a race against time, and an uncertain amount of time at that; and slowing down the download is not recommended for user satisfaction.
If it’s a small file, it will physically download before the user even sees the dialog, so the server will be useless. Also consider that some download manager extensions take over the job, and they are not guaranteed to behave the same as a vanilla browser. Forcing a wait can be treacherous to someone with a slow hard drive that takes “forever” to “finish” a download; we’ve all experienced this, and not being able to continue while the “spinny” winds down would lower user satisfaction, to put it mildly.
In short, there’s no simple way, and really no way in general, except for huge files you know will take a long time to download. I’ve spent a lot of blood sweat and tears trying to provide my download.js users the ability, but there are simply no good options. Ryan dahl initially wrote node.js so he could provide his users an upload progress bar, maybe someone will make a server/client package to make it easy to do the same for downloads.