Last modified: 2014-03-19 11:09:57 UTC
Since bug 41573 the item gets on your watchlist when watchdefault is set and you save a change. But the watch indicator of the actual page doesn't change because the page isn't reloaded. It would be nice to start the watch animation on submitting the change when watchdefault is set and the item is currently not watched. Set the watch indicator to status watched when the submit was successful and the item is on your watchlist. Set the watch indicator back to status not watched when the submit failed and the item is not on you watchlist.
Change 112464 had a related patch set uploaded by Thiemo Mättig (WMDE): Update watchlist link/star when doing Wikibase edits https://gerrit.wikimedia.org/r/112464
Change 112464 merged by jenkins-bot: Update watchlist link/star when doing Wikibase edits https://gerrit.wikimedia.org/r/112464
The solution from https://gerrit.wikimedia.org/r/112464 doesn't work reliably. I just edited an unwatched item. On saving the star started to rotate. When the saving finished the star stops rotating and switched back to the white star instead to the blue star. When I reload the page the star was blue. So adding to the watch list by the POST request works but the GET request directly after saving for checking the watch status doesn't get the new state reliable. Maybe the GET request gets answered by a different server in comparison to the POST request and the state in the database was not updated yet. A more reliable solution is to integrate the changed state of the watch list into the response of the POST request. For comparison: The index.php also answers with the new state of the watch list state in the response.
That is similar to bug 26292.
(In reply to Fomafix from comment #3) > the star stops rotating and switched back to the white star [...] > Maybe the GET request gets answered by a different server This is an other, loosely connected issue. Can we move this to a new report, please? What if (I know this is not really a solution, just think about it) we don't do an API call at all? The star always turns blue if watchdefault is enabled. The question is: Are there any cases when this will be wrong? (The star turns blue but shouldn't.) And how big is the impact of these (probably rare) cases compared to the impact of the original issue?
Yes let's please track this in the other bug Helder mentioned.
Bug 26292 is a different problem. In bug 26292 there is no JavaScript/Ajax and no API and the change is done by a single POST. I can reproduce bug 26292 on enwiki but not on a local wiki. But when the implementation for Wikibase is changed from a separate GET to a combined POST with the problem may also occur on API. Just guessing the server-state of the watch list on client site is problematic because all error paths has to implemented reimplemented on client side.
(In reply to Fomafix from comment #7) > In bug 26292 there is no JavaScript/Ajax and no API As I said you can create a new report to help us keep track of the impact this issue haves on the Wikidata users. As mentioned we belief it depends on bug 26292 or at least shares the same root cause. And will not be easy to fix, unfortunately. > guessing the server-state of the watch list on client site is problematic > because all error paths has to [...] reimplemented on client side. Yes, that's totally true. However, if it turns out the impact of some watchlist star animations wrongly turning white (as you described) is much bigger than a few watchlist stars wrongly turning blue (my naive suggestion) it may be a reasonable workaround instead of spending developers time on more complex solutions (like redesigning the API).
