When accessing RecentChanges as a user with Rollback rights, the rollback links will work properly on page laod. However, when updating the list of items shown on the RecentChanges page via the filters on the right (for example, increasing the number of "Results to show" or changing the time period that is shown) or by letting new elements appear through the live update feature, new items will not have the rollback confirmation JavaScript event attached to them, meaning users will be redirected when clicking on a rollback link rather than being asked to confirm their action on the page.
Affected users are still prompted to confirm the rollback as the non-JS rollback confirmation will take over, so this is not a critical issue and users can not accidentally rollback anything, it's mainly a user-experience problem.
The issue itself is kind of related to how the "Confirmables" work that we are using in the code to implement the user confirmation:
As far as I can see, we can either fix this by making changes to the Confirmable script as the issue is strongly linked to it (since we are simply re-using it, much like the Thanks extension). Alternatively, we can also consider this a minor issue and postpone this until a better, more permanent solution is found for the user interface. However, I assume the latter will take too much time, so it may be best to first fix the current approach before we move forward.
A solution may be to implement delegated event handlers into the Confirmable script, but we may need to double-check this.