Users with a tab open before a deploy carry on running the previous build until they do a genuine page load. Logging out and back in does not do it, and neither does reopening the site in the same tab. From the user's side a fault that has already been fixed simply looks unfixed, which generates support traffic for problems that no longer exist.
Each build now stamps its run number into the image as BUILD_NUMBER and serves it from /api/version. The running app records the build number it started with, then rechecks once a minute and whenever the tab regains focus. When the deployed build is newer, the tab reloads itself with no prompt and no decision for the user.
Two things the reload will not do. It will not interrupt work in progress: if a modal is open or the user has typed into anything since the last navigation, the reload waits until they navigate away. It will not loop during a rolling deploy across machines: build numbers are compared rather than tested for inequality, so a tab only ever moves forward.
The first deploy carrying this change cannot rescue tabs already open on the previous build, since that code has no version check in it. Those still need one manual refresh. Every deploy after this one is automatic.