Visiting your own talk page should mark user talk page notifications as read
Closed, ResolvedPublic

Assigned To
None
Priority
Unbreak Now!
Author
Eloquence
Subscribers
Krenair, howief, Vibhabamba and 5 others
Projects
Reference
bz47912
Description

When I receive an email notification about new talk page messages and click the link to visit my talk page, my notification count on the web view is still increased by 1 until I expand the flyout, even though I've just read the message.

In the pre-Echo model, any visit to your own user talk page would permanently clear the Orange Bar of Doom, and we should probably strive for equivalent behavior with Echo, i.e. mark any notifications about new messages as read once I visit my own user talk page.


Version: unspecified
Severity: major

bzimport added a project: Echo.Via ConduitNov 22 2014, 1:26 AM
bzimport set Reference to bz47912.
Eloquence created this task.Via LegacyMay 1 2013, 6:09 AM
Fabrice_Florin added a comment.Via ConduitMay 1 2013, 6:32 AM

Thanks for filing this, Erik.

It 'echoes' a similar request from the talk page:

http://en.wikipedia.org/wiki/Wikipedia_talk:Notifications#It_doesn.27t_go_away.21

However, this may not be trivial to implement, as Luke suggests.

For now, I'm giving this a high priority, to be lowered if it requires more development than we can afford in this phase.

bzimport added a comment.Via ConduitMay 1 2013, 4:51 PM

lwelling wrote:

More generally, a visit to the target link of any notification should mark that notification as read.

Ideally we could do it in a general way for all types, not tackle only some and leave user's with inconsistent behavior.

Doing it for all types would also solve the debate about marking as read when the flyout is shown. We did not get strong concensus before launch on how those should be flagged whether the flyout should show read notifications at all. A more precise algorithm for marking read should make that debate clearer as the main sticking point was the possibility of missing talk page messages.

An alternative non-type specific proposal would be that links in the email are recognizable and mark their website twin as read. That would not be as generally useful, but it would solve this use case without introducing inconsistent behavior and would be fairly easy to implement.

Krenair added a comment.Via ConduitMay 6 2013, 2:53 PM
  • Bug 48124 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitMay 6 2013, 2:55 PM

Thehelpfulonewiki wrote:

Bumping priority to match 48124

bzimport added a comment.Via ConduitMay 6 2013, 2:56 PM

Thehelpfulonewiki wrote:

Copying Fabrice's comment from there:


Fabrice Florin 2013-05-06 07:36:38 UTC

Anytime a user visits their own talk page, all their message notifications
should be 'marked as read' in the flyout and archive.

This issue was reported by Risker and other users, who point out that visiting
their talk page doesn't clear notifications in the red badge, as described on
the Notifications talk page:
http://en.wikipedia.org/wiki/Wikipedia_talk:Notifications#Cannot_reset_number_by_going_to_page

Note that this problem could be exacerbated if we provide a secondary path to
talk, such as the New Message Indicator feature discussed here:
http://en.wikipedia.org/wiki/Wikipedia:Notifications/New_message_indicator

So we would need to fix this issue first, before we can deploy a new message
indicator or OBOM, that provide a secondary path to talk.

To clarify the proposed logic, a talk message would be 'marked as read' if:
a) user visits their talk page
b) user clicks on the red badge

(if flyout includes that message)

c) user clicks on 'Mark all as read'

(if flyout does not include that message)

d) user visits the archive page

(and clicks 'More' to show that message, if not visible)

For more info about 'Mark all as read', check this feature requirement:
http://www.mediawiki.org/wiki/Echo/Feature_requirements#Mark_all_as_read

bzimport added a comment.Via ConduitMay 15 2013, 4:58 PM

johnnyfitz wrote:

What are the chances of bringing back the original message notification w/ the orange banner? Again, it was impossible to overlook, as I have done with this tiny red box. The additional small orange banner was a minor improvement however we don't need to see a list of messages (last msg, first) as they appear in that order at the bottom of our talk pages -- and there is edit history. Seems like someone is going through a lot of trouble to reinvent the wheel. -- A fifth wheel no less.

... (also), that tiny red box still appears until you click on it too. Going to your talk page won't make it disappear -- and clicking on it doesn't take you to your talk page. You now have to select a message from a list.

How much server resources will be bled away from the rest of Wikipedia to keep all of this unneeded stuff going?

~~~~

gerritbot added a comment.Via ConduitMay 24 2013, 11:04 PM

Related URL: https://gerrit.wikimedia.org/r/65349 (Gerrit Change Iadfe3cf7927d5318f89ba17f067000f9399060af)

MZMcBride added a comment.Via ConduitMay 24 2013, 11:05 PM

(In reply to comment #1)

Thanks for filing this, Erik.

My thanks as well. This has been bothering me. I'm glad to see there's now a proposed fix (comment 7).

Aklapper added a comment.Via ConduitMay 25 2013, 1:29 PM

(In reply to comment #6)

What are the chances of bringing back the original message notification w/
the orange banner?

johnnyfitz: Feel free to discuss on http://en.wikipedia.org/wiki/Wikipedia_talk:Notifications . Your question is off-topic for this specific bug report which is only about "Visiting your own talk page should mark user talk page notifications as read". Thanks for your understanding.

gerritbot added a comment.Via ConduitMay 30 2013, 6:46 PM

https://gerrit.wikimedia.org/r/65349 (Gerrit Change Iadfe3cf7927d5318f89ba17f067000f9399060af) | change APPROVED and MERGED [by jenkins-bot]

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.