I got a failed login attempt notification today. I have a strong password and 2FA on my account, so I dismissed the notification. However, it re-appeared 2 seconds after. I have tried to dismiss it again from other projects, but nothing works.
Description
Details
Subject | Repo | Branch | Lines +/- | |
---|---|---|---|---|
Make markasread parameter work cross-wiki | mediawiki/extensions/Echo | master | +141 -61 |
Related Objects
- Mentioned In
- T264834: Users can't mark their Notifications from loginwiki as read because they don't have the `writeapi` permission
T203598: 'Failed login' notification - cannot mark as read - Mentioned Here
- T121930: Cross-wiki mark as read doesn't work
T132084: Notify editors that they are now eligible for the Wikipedia Library program
T180988: Can't dismiss the notice I got on login.wikimedia.org
Event Timeline
Maybe T180988: Can't dismiss the notice I got on login.wikimedia.org is about the same problem.
Probably. Do either of you have Privacy Badger, AdBlock or a similar plugin enabled? If so, does (temporarily) disabling such plugins fix it?
I tried Chrome's incognito mode with adblock disabled and didn't work. There are no other plugins. And yesterday I used the Firefox 57. So it's not about the browser.
I experience the same issue. I stated this initially in the talk page of community tech page. The only way I could dismiss them is by going to Special:Notifications and marking them as read. I did try restarting Firefox with Add-ons disabled and the result was the same. I also tried clicking on the notification using Chromium and it had no effect too.
My issue was not a login related notification, but "You just made your first edit; thank you, and welcome!" on https://login.wikimedia.org when I created there a common.js page for myself. Then I deleted the page, restored, but could not turn off the notification. After 6 months I restored the page (https://login.wikimedia.org/w/index.php?title=Special%3ALog&type=delete&user=Stryn&page=&year=&month=-1&tagfilter=&hide_patrol_log=1&hide_tag_log=1) and marked the notification as read and finally it was gone. So I don't have this problem anymore.
My issue was with failed login notifications. Clicking on the notification takes me to https://www.mediawiki.org/wiki/Help:Login_notifications but doesn't mark the notification as read despite the presence of the ?markasread= parameter. For the time being I'm able to dismiss them by clicking on the blue dot that appears near the notification, though.
Thanks for your comments @Stryn and @Kaartic, they helped me understand what's going on here.
The link on a failed login notification sends you to mediawiki.org, but the notification came from login.wikimedia.org. The markasread parameter doesn't work because the notification ID in it refers to a notification on loginwiki, but mediawikiwiki looks it up in its own database and finds nothing (or finds an unrelated notification, but it most likely belongs to a different user so it'll refuse to change it). You don't notice this effect for most notifications, because almost all notifications link to a page on the same wiki.
In order to fix this, we either have to change this link to go to loginwiki (then it'll just work), or put the wiki name in the markasread parameter and have Echo proxy a markasread request back to the originating wiki. A side benefit of doing this would be that we can use the same proxy functionality for the regular mark as read button (the blue circle), which would prevent plugins like Privacy Badger and AdBlock from breaking cross-wiki mark-as-read (see T121930: Cross-wiki mark as read doesn't work). See also T132084#2779920 for the last time we discussed this issue.
So there is an unspoken rule that the notification should originate from and link to the same wikis? We should enforce this in the code, if possible.
In order to fix this, we either have to change this link to go to loginwiki (then it'll just work), or put the wiki name in the markasread parameter and have Echo proxy a markasread request back to the originating wiki. A side benefit of doing this would be that we can use the same proxy functionality for the regular mark as read button (the blue circle), which would prevent plugins like Privacy Badger and AdBlock from breaking cross-wiki mark-as-read (see T121930: Cross-wiki mark as read doesn't work). See also T132084#2779920 for the last time we discussed this issue.
We discussed the idea of sending users to loginwiki but it didn't work out because several people were against directly users to that wiki (obscure, used for technical purposes only etc).
FYI, we got two more reports about this happening today: https://www.mediawiki.org/wiki/Topic:Ujerw9yjfnmcocyo
Or at least document what will happen if you try this. And maybe detect what's happening and not add the markasread parameter.
However, I'd prefer to just make this work, as outlined in my previous comment. We are about to have some time to do maintenance work while we figure out what product work to do next, so I have put this task on the short list of tasks to do during that time.
We discussed the idea of sending users to loginwiki but it didn't work out because several people were against directly users to that wiki (obscure, used for technical purposes only etc).
Yeah, that makes sense, and it also makes sense that the notification originates from loginwiki. Cross-wiki notifications should really support cross-wiki link targets though, so it's not really your fault, it's ours :)
Change 457681 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/Echo@master] Make markasread parameter work cross-wiki
Change 457681 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Make markasread parameter work cross-wiki
Yes, it should. A notification that was generated before this change should now get dismissed when clicked. This particular bug might not be testable in beta labs though, because en.wikipedia.beta.wmflabs.org and mediawiki.org are not in the same wiki family.