Page MenuHomePhabricator

Cross-wiki mark as read doesn't work
Closed, ResolvedPublic

Description

If you click the X on a cross-wiki notification, it disappears from the UI, but it's not marked as read on the remote wiki. If you refresh the page, it comes back as unread. AFAICT no XHR request is sent when I click the X.

Additionally, clicking the X for the group item containing foreign notifications also doesn't do anything (apart from hiding the whole group item until you refresh the page).

Update 2016-05-14 01:15 UTC: it looks like this may be caused by PrivacyBadger. To work around that, we'd have to proxy mark-as-read requests through the local API.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

As far as I remember (and please correct me if I remember wrong -- or perhaps we need to rethink this) here's what we agreed:

  1. A bundle item (the group notification) is doing nothing for "X" button except disappearing. This is so that users won't lose their notifications as a bundle in several remote wikis.
  2. A specific cross-wiki item should be marked as read in the foreign wiki when its "X" button is clicked.

As far as I understand, we've agreed that the user should "mean it" in order to mark a cross-wiki item as read -- that is, not to globally mark-all-read outside of its local wiki.

So in this bug, we should make sure that *specific* items in the bundle are sending the request to be marked as read, individually, while the group 'mark as read' does nothing except for hiding the UI until the next time you refresh.

I am not sure if this makes 100% sense, but I do have concerns about having the entire bundle (that may include several notifications from several external wikis) indiscriminately mark all those foreign notifications as read in one fell swoop... worth discussing, at least.

In any case, I am verifying that the individual "mark as read" "X" buttons are marking the specific notification items as read.

After double-checking the code, this is the way things behave right now. Individual sub-items in cross-wiki notifications are marked as read individually per their wiki, but a bundle does nothing in the API.

The "Demo" page does nothing, though, as there is fake cross-wiki notifications there (it returns a resolved $.Deferred() object)

I am having trouble installing an actual, live way of producing cross-wiki notifications in my local installation, so I can't verify this is working properly live, but code-wise, it absolutely should. The NetworkHandler calls for its ForeignApi object to send "markRead" by ID.

We should discuss what to do with the 'X' of the bundles, though. I have several concerns about making that button mark all as read.

  1. When the cross-wiki bundle marks "all" as read, does it mark *all* notifications in those remote wikis as read, or only the ones that are in the bundle? This is important, because bundles may have limited number of items. We may only see 5-6 items in the bundle when the actual remote wiki has 20 or more. If we mimic the local "mark all as read" then all of those 20 notifications (or however many) will be marked as unread. If we have a bundle with several remote wikis (which will happen, most commonly) then we end up marking "all read" for many remote wikis. I'm not at all sure that is intended or smart to do from the user's perspective.
  1. We have a small technical issue to resolve (that is less of a blocker to this feature, since it can be fixed, but it's worth considering) -- bundles know of the number of notifications they have, but they don't know about the specific sub-notifications until we open them (that is when the API request is sent to the remote wikis to fetch the actual notifications. If we mark all read before we fetched the notifications, we have two options: (a) We decide we don't care about the sub items specifically, and send the remote wikis "mark all as read" which will mark *all* notifications as read in that wiki (see above, I don't think that's wise) or (b) We fetch the notifications that were supposed to be there, then mark all of those as read specifically as a bunch.

Either way, we should discuss the "mark all read" behavior in cross-wiki bundles. @Pginer-WMF and @jmatazzoni should probably pitch in here. What do you guys think?

Can I back up a step here? I'd like to understand how you get bundled notifications from multiple wikis. My understanding was that notifications are bundled only if they pertain to the very same topic/page/post, etc. So, it can't happen for edit-user-talk, since each talk page is a different page. Or for flow-new-topic, flow-post-reply or flow-post-edited. So are we just talking about page-linked? Or do I misunderstand bundles? (Likely.)

Internal bundles are as you say -- bundled by topic/page/post.

Cross-wiki bundle is a single bundle that contains all your notifications from external wikis. It may have "groups" in it, say [English] and [Spanish] where each shows you the bundle notification from the prospective wiki.

There's a task that describes the design of cross-wiki bundled notifications, I will try and find it for samples.

There it is: T114350: Notifications Panel: Support cross-wiki notifications

Notice the design of the bundle with notifications from "Commons" and "Wikipedia - Spanish" (The third image from the top)

After double-checking the code, this is the way things behave right now. Individual sub-items in cross-wiki notifications are marked as read individually per their wiki, but a bundle does nothing in the API.

Having X on the entire bundle not do anything sounds fine to me. But marking individual foreign notifications as read also isn't working for me: I never see an API request when I click X, the notification just disappears.

With cross-wiki notifications we have notifications from other wikis represented in a group (or bundle). The bundle represents that group of notifications. If we provide a way to discard that group, I think it is acceptable to either (a) mark the included notifications as read or (b) hide the group for it not to get in the way of processing local notifications.

Even in the second case I think the bundle should not become visible again for the same notifications (or at least not surfacing again until new notifications appear for other wikis). It does not make much sense that I discard cross wiki notifications again and again because the same group of elements keep appearing as I navigate the site.

For consistency, I'd make the mark as read action ("X") to propagate when applied to a bundle. That is, when I click on the "X" for "More messages from commons and other wikis" to mark those messages as read (as if I was expanding the item and click on the "X" for each individual item it contains). I think this can be aligned with the user expectations based on the way individual items behave. For example, if my flag image was linked from 50 articles on different wikis, a quick way to mark these as read could be helpful without additional navigation or confirm items individually.

The only exception I'd make is when clicking on the panel "Mark all as read", in that context is not clear that the expectation is for the effects to propagate to other wikis. I'd restrict that to affect only local notifications (and making only available then) since the user is just one click away to do so (if we support such thing from the cross-wiki bundle "X" action).

@Pginer-WMF, I am having reservations with this method, especially due to this concern/scenario:

What happens if you have 50 notifications in Commons and 20 in Spanish, and you're viewing the notifications in Hebrew wiki. I assume the cross-wiki bundle will be limited, so we won't see the 70 notifications, but only about 20 (?) What happens if I click "mark as read" for the whole bundle? Will it just mark as read all of the ones I currently *see* in the bundle, or will it mark as read *all* of my unread notifications in the remote wikis?

And if it only marks those that I see -- what happens if I click that 'mark all read' button *before* I opened the bundle? I didn't "see" anything yet... am I marking everything as read in all wikis? is there even a reason to have the "mark as read" button on an unopened bundle? Maybe not?

I don't know if this is all that intuitive to use, to be honest. I am much more for replacing the "X" (mark-as-read) button in the bundle with something like "HIDE", or something ilke that. I'm not sure I like the idea that a single click in a remote wiki can mark *all* of my notifications in *all* the wikis I am active in as read.

If not that, then at least let's have the "mark all read" mark *only* the items inside the bundle, and not actually all notifications in the remote wikis. Though that is, too, a different behavior than if we click "mark all read" *locally*.

What do you think?

What do you think?

Marking only the items in the bundle makes sense. Otherwise it can be confusing to get side-effects you cannot anticipate.

These kind of actions that are applied to many elements became more or less useful depending on the volume of elements. Something similar happens with the "mark all as read". For a small set of notifications that you get at first sight it can be convenient but as the list goes long there are probably exceptions you want to keep (maybe having a way to pin that is not affected by the "mark all as read" action could reduce this issue but that is a different story). Once the list of unread notifications gets too long, the "mark all as read" only gets useful as a way to start from scratch. I guess something similar could happen for the "mark these cross-wiki notifications as read".

Marking only the items in the bundle makes sense. Otherwise it can be confusing to get side-effects you cannot anticipate.

These kind of actions that are applied to many elements became more or less useful depending on the volume of elements. Something similar happens with the "mark all as read". For a small set of notifications that you get at first sight it can be convenient but as the list goes long there are probably exceptions you want to keep (maybe having a way to pin that is not affected by the "mark all as read" action could reduce this issue but that is a different story). Once the list of unread notifications gets too long, the "mark all as read" only gets useful as a way to start from scratch. I guess something similar could happen for the "mark these cross-wiki notifications as read".

Hm. I'm still concerned, though. A few issues:

Concern #1:

When you're in the local wiki, you open the popup and see the notifications you have, then you can "mark all as read" and have them change. But it's not quite the same in a bundle; for one, we still show the "X" button when the bundle is *closed*. If the user clicks on it, they mark certain notifications (the ones in the bundle, which the user hasn't seen yet) as read. The user didn't see those notifications yet, and since we agree that only the ones that are *in* the bundle are changed, they may actually get a weird behavior where SOME notifications are marked as read and not others, without understanding why.

So, should we maybe hide the "X" button in a bundle until, at least, the bundle is open for the first time, and the user saw the notifications? I think that might be better behavior and save some unintended issues.

Concern #2:

The second concern is continuing my theorized situation above:

  • Say you have 50 notifications from Commons and 20 from English and you are in Hebrew wiki.
  • We agree that we don't show the user all 70 notifications. So, say we show 10 notifications each (20 total in the bundle, showing 2 "groups" of 10 each).
  • The user now clicks the bundle's "X" mark-as-read button. Those notifications are remotely marked as read.
  • Now we have this: 40 unread notifications in Commons, and 10 unread notifications in English wiki.
  • The user refreshes the page. Now, the user sees another bundle, with 20 new unread notifications (10 each) from Commons and English.

I'm not entirely sure if this behavior makes complete sense or if it is not confusing?

And, lastly, this point should not be what we base any sort of decision on, but I feel I should raise it: If we do allow the user to "mark as read" a bundle before it is initially opened, the process is going to be technically *slightly* more complicated, because we will first need to fetch those notifications (so we know what they are) and then mark them as read from each wiki. This is a technical concern that can be solved, and we definitely shouldn't take that as a reason not to do something for the sake of the user experience, but we should consider that issue -- we may want to add something to the API if we do decide to go this route to make this less expensive.

Anyways, I'm deferring to your expertise, @Pginer-WMF, but I do have the above concerns. I personally also feel very worried when we have a button that automatically reaches out so "far" (to several wikis, to multiple notifications that you may not have looked at) and changes them. It feels to me like one of those BIG RED BUTTONS that people are seriously afraid to touch because the number of things they affect is cascaded.

Then again, we're really only talking about "mark as read," not "implode the internet," so there's that.

@Mooeypoo, your concerns are valid.
Regarding the first I'm not very worried:

  • Similarly to what happens when a user closes the browser with many tabs, I'm more in favor of not warning as long as there is a way to recover the last session when you open a new window again (I understand the logic behind Firefox to warn the user, but I prefer Chrome's approach where they don't). in our case, notifications are not lost.
  • The user intent was clear. What was the user trying to achieve by clicking the "X" if it was not to apply the same action as the rest of the "X"s? Users navigate through different pages as they process notifications so even if the user is not expanding the cross-wiki bundle now, the user may have done a few seconds ago and may know what the contents are.
  • I'd avoid the "X" to appear on expanding the bundle, since that may suggest that this action for collapsing it again, leading to undesired side-effects.

Regarding the second concern, I agree it leads to inconsistent situations.

Overall, I think it is ok to start by not showing the "X" action for the cross-wiki bundle at all in our first iteration. So this does not become a blocker to get the feature in front of users (through the beta channel) and learn from that.

We can reconsider how to better add this functionality and the related aspects such as: how to communicate that there are more notifications than the ones displayed, how to adjust those thresholds to minimise problematic situations, how to play well with "mark all as read" action from the panel, and how to keep consistency with non-cross-wiki expandable bundles where we need to provide the "X" action as we do now.

@Mooeypoo, your concerns are valid.
Regarding the first I'm not very worried:

  • Similarly to what happens when a user closes the browser with many tabs, I'm more in favor of not warning as long as there is a way to recover the last session when you open a new window again (I understand the logic behind Firefox to warn the user, but I prefer Chrome's approach where they don't). in our case, notifications are not lost.
  • The user intent was clear. What was the user trying to achieve by clicking the "X" if it was not to apply the same action as the rest of the "X"s? Users navigate through different pages as they process notifications so even if the user is not expanding the cross-wiki bundle now, the user may have done a few seconds ago and may know what the contents are.
  • I'd avoid the "X" to appear on expanding the bundle, since that may suggest that this action for collapsing it again, leading to undesired side-effects.

Hm, those are good points, but once again, I want to emphasize that our case is the user marking notifications they haven't seen yet as read.
But I accept the point. Also, you are right that this isn't as dire-consequences as the discussion we're having may make it out to be...

Regarding the second concern, I agree it leads to inconsistent situations.

Overall, I think it is ok to start by not showing the "X" action for the cross-wiki bundle at all in our first iteration. So this does not become a blocker to get the feature in front of users (through the beta channel) and learn from that.

We can do it either way -- start with the X that marks everything as read and check into things for the iteration, or hide that button and check it for the iteration.
Technically speaking, hiding that button is incredible easy, so I will go ahead and implement the "mark all read" for the bundle, and we can decide to hide the button after that if we want to.

But I think we both agree that we might want to check into this behavior and whether it is confusing or not in the next iterations.

Change 261290 had a related patch set uploaded (by Mooeypoo):
Mark bundles as read except when it is automatic

https://gerrit.wikimedia.org/r/261290

For the record: on the 12/29 Collab Team Discussion, we decided to go with the plan to remove the X for the X-Wiki bundles and make people X out bundled notifications individually.

Change 261290 merged by jenkins-bot:
Mark bundles as read except when it is automatic

https://gerrit.wikimedia.org/r/261290

Change 264893 had a related patch set uploaded (by Mooeypoo):
Hide 'mark as read' for foreign NotificationGroupItem bundles

https://gerrit.wikimedia.org/r/264893

Change 264893 merged by jenkins-bot:
Hide 'mark as read' for foreign NotificationGroupItem bundles

https://gerrit.wikimedia.org/r/264893

Checked in betalabs. Seems to be consistent - clicking on either X icon or 'Mark as read'

  • no 'Mark as read' for cross-wiki bundled notifications, only for individual notifications
  • removes the notifications from cross-wiki expandable flyout
  • marks those notifications as Read in the wiki of origin
  • works vice versa too: 'Mark as read' in the wiki of notification origin will remove the notification from the cross-wiki expandable notification fly-out.

There is 'Mark all as read' option which appears when there is a mix of cross-wiki and local wiki notifications. This option when click will mark as read all notifications - from other wikis and from the local wiki.

jmatazzoni set Security to None.

I'm reopening the task due to Fæ's feedback from Commons: "if you have 7 global notices on 7 different projects, you can mark them all as read on project 1, but then when you go to project 2 you find 6 notices still open, so effectively you end up being forced to mark 36 notices as read when in truth there should have just been the original 7."

Some feedback from en.wp too, where some people don't manage to clear x-wiki notifications.

It does not seem to be reproducible straightforwardly, but I did see several problems.

  1. The most obvious one is with Arabic wikipeida - https://ar.wikipedia.org/wiki/%D8%A7%D9%84%D8%B5%D9%81%D8%AD%D8%A9_%D8%A7%D9%84%D8%B1%D8%A6%D9%8A%D8%B3%D9%8A%D8%A9

The messages were marked as read, and after that the count got stuck - the flyout displays 'No notifications' - after several refreshings.

Screen Shot 2016-05-13 at 12.25.15 PM.png (226×576 px, 36 KB)

Also, notice the label exposing PLURAL:$1

Screen Shot 2016-05-13 at 12.33.42 PM.png (263×646 px, 51 KB)

Screen Shot 2016-05-13 at 12.24.03 PM.png (243×603 px, 52 KB)

  1. Incorrect (delayed) count happens most likely when the number of wikis is more than four.

It looks like notifications were in fact marked as read, but the counts weren't updating. So I'm gonna dupe this to T135246: Wrong notification counts being shown due to cache pollution coming from non-SUL wikis. Please reopen if you find cases where notifications themselves are still shown as unread even after being marked as read.

Reading the enwiki report more closely, it's not about stale counts, it actually is about not being able to mark as read across wikis. I suspect this may be a Privacy Badger / AdBlock issue.

I can reproduce this now: I have a notification on ptwikibooks that I can't mark as read. For some reason ptwikibooks is rejecting my CORS request from mediawiki.org.

Looks like it's PrivacyBadger.

I spoke to the Privacy Badger developer and he said he's working on code to fix this general problem (not recognizing that e.g. wikipedia.org and wiktionary.org are the same party), but that it won't be in the upcoming release.

In the meantime, we should log these failures so we can see how often they happen, and consider proxying mark-as-read (and seentime?) requests through the local domain.

Change 457680 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/Echo@master] Use API proxying for markasread requests in the front end

https://gerrit.wikimedia.org/r/457680

Change 457680 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Use API proxying for markasread requests in the front end

https://gerrit.wikimedia.org/r/457680

Etonkovidova closed this task as Resolved.EditedSep 6 2018, 4:39 AM

Fixed - checked in betalabs.
Re-checked T135292 - the issue has much lesser scope now; updated the description.