Last modified: 2013-06-07 02:10:24 UTC
A moment ago when I opened https://wikitech.wikimedia.org/ I had 11 unread notifications. It mentions " (showing 7/10)" on top. After looking over the 7 messages quickly I want to see the other 3. There is no pagination so I I click "Mark all as read". Now I have 0 unread notifications. Where did the other 3 go? I haven't read those yet. This happening suggests another bug existing (technical one as opposed to a usability one). I suspect this is implemented by an API call that says "mark all" (not just in the UI but in the API as well). Which means it is subject to a logic error in race conditions. Events happening between me opening the fly-out and me clicking "mark all as read" (or rather, the moment the server processes that request), there can be new notifications. Even if we'd have perfect real-time push notifications, this is unreliable. It should probably add the ids of what it should mark to the API. e.g. like ids[]=1&ids[]=2 or ids=1|2|3. See ApiPatrol and ApiQueryBase for similar multi-value actions. Marking as "usability", and also "code-update-regression" as I believe this made the interface worse/dangerous for the user.
The button only appears if you have unread notifications you can't see and it's only purpose is to mark those unread notifications you can't see as read. So the bug you describe is exactly how the feature is supposed to work. See https://www.mediawiki.org/wiki/Echo/Feature_requirements#Mark_all_as_read Clearly the interface is confusing, but the button itself is working as intended. I'm going to close this bug as invalid, but I would encourage you to file a bug on the interface itself being confusing (or requesting a way to load more notifications in the interface).
