| Trizek-WMF | |
| Jul 1 2016, 8:29 AM |
| F4245423: Screen Shot 2016-07-06 at 11.42.01 AM.png | |
| Jul 6 2016, 6:50 PM |
| F4221231: tiny-blue-dot.mov | |
| Jul 1 2016, 2:47 PM |
Whatamidoing reports "Every normal day begins with going to Notifications and telling it to mark someone's user talk page as read (a cross wiki notification). But when I click the blue dot, it takes me to the new thread (not what I want) and does *not* mark it read!"
I think she uses Safari.
It works for me on Chrome 49.0.2623.108.
Maybe a screenshot would help. It sounds like the div or click area for the notification at the left is invading the area of the blue dot, but even if I make the window very narrow I can still click the blue dot without problems.
If she uses Safari it's very plausible that this is a CSS issue / browser bug. If I get a chance later today I'll try to test with Safari VM.
Hello, @Trizek-WMF? Why do you think this task has something with T139122? This one is a bug. That one a request for improvement of different feature.
Here is a short demo showing how the notification "unread" dot, when showing a notification from another wiki, does not behave properly.
Also, that blue dot is way too small! :)
I believe I've experienced the same issue as @CKoerner_WMF, although it happened fast and I haven't been able to reproduce it.
Chrome 51.0.2704.103 Mac 10.11.5
I may have experienced something similar: T139339: Cross-wiki mark as read redirects to the page instead of actually mark as read
I just tested this on beta and on the live site in Mac Safari version 9.0 (11601.1.56), and did not see any problem.
This is half-fixed.
Clicking on this blue dot at Meta:
takes me to James F's user talk page on mw.org. I am not clicking on the message; I am clicking on the blue dot itself (note the presence of the tooltip), whose alleged purpose is to mark the notification as read without taking me to the page.
This is happening now, in Safari 9.1.1 and Firefox 47.0 on Mac OS 10.10.5 (14F1808).
However, as an improvement over the previous behavior, clicking the dot is marking the notification as read. The next step is to make it stop taking me to the page that I don't want to read.
I'm still not seeing it. @Whatamidoing-WMF, would you mind trying this on the beta site? That would have the newest code. Perhaps whatever it is has been fixed...
I was not able to actually reproduce the bug, but watching the screen recording I noticed that that the blue dot was actually turned to the empty circle upon clicking indicating that the status of the notification was, in fact, changed.
In the screen recording the blue dot was clicked several time and there was a movement of cursor (with continuing clicking?)- so the user was redirected to the page.
If you are interested to hear this, yesterday I saw again the same problem: I marked the blue dot manually as read, the number of notifications was 0, and an hour after that a new notification received and the old one surprisingly was remarked blue again, so the number become 2.
Elena writes:
In the screen recording the blue dot was clicked several time and there was a movement of cursor (with continuing clicking?)- so the user was redirected to the page.
Yes, I saw that too. But later in the recording the blue dot itself clearly does redirect to a different page.
Anyway, @Whatamidoing-WMF, if it's working for you now, as you note above (I think), can we close this? (@IKhitron, your count problems would seem to be a different issue.)
So the task name is too comprehensive. I thought this is a problem. It happens at least once every day in the last days, whebn the blue dot appeared.
Thx, @IKhitron - yes, there may be something. But it's really hard to reproduce. I tried to test it - still did not get definite results (with reproducible steps). I've set up some tests for tomorrow and will report back.
To summarize two issues reported on the task:
I was checking T138569: Global notifications still appearing as unread on other wikis even after reading them suspecting that the issue is more severe (e.g. local notifications spontaneously revert their status) - all looks fine.
Unfortunately, I don't see a way how to prove this point. But it happened today again, 7 times.
@IKhitron okay, this is worrying - we can't seem to properly reproduce a bug you're experiencing fairly regularly. I want to pinpoint the issue without confusing things further in this more general bug report, so I split this problem up to its own task T140309: In some cases notifications that were marked read, reappear as unread again
I've raised a couple of questions, if you could help me try and sort it out in that task, that will be extremely helpful. Thanks!