Look at diffs from my watchlist on my mobile phone. Big green "Thank" button is too easily accidentally pressed (large and near to phone's "back" button), and does not then ask for confirmation as the desktop version does. I have accidentally thanked editors, through fat finger accidents. It's ironic that I get asked for confirmation after clicking the small "thank" link on desktop, but not when touching a large touchscreen button here.
Reproducible: Didn't try
Please provide a forum on English Wikipedia where questions about mobile access can be discussed.
= Acceptance criteria
 When clicking thanks button an API request is queued and a notification is shown
 When undo in the notification is clicked, the API request is cancelled
 When the notification disappears the API request is sent
 When the API request is fulfilled, the thank button label changes to "Thanked"
= Developer notes
Talking to @Mooeypoo, apparently the issue with undoing Thanks is how to handle things in the log. Do we log that a user undid a thank or do we not log that at all.
As a result of this, we plan to introduce a client side delay on the api call allowing user to click again to undo:
We will leave 5* seconds between clicking and sending the thanks - allowing user time to click it again to cancel.
(note:delay intentionally long so its obvious there is a delay,but in practice I suspect 2seconds should be enough)
@alexhollender provided these mocks:
When clicking thank, the button should change state and a a "Thanking TestTest... UNDO toast will show.
if the user hits undo the API request will be cancelled.
If the user does nothing, the API request is sent.
On completion of the API request, a toast will show saying "You have thanked TestTest."
If the user clicks undo, the thank button should return to its unclicked state.
* subject to tweaking
= Dismissed solutions
== We use window.confirm
This avoids having to fiddle with the UI behaviour on the client.