This is intended behaviour.

If this behavior is intended, it is rather disappointing.

If i understood correctly, one of the design ideas of LiquidThreads was to keep the good things in MediaWiki's talk pages. Currently, if my user talk page on MediaWiki changes, i get the orange banner saying that i have new messages. Then it is enough to open my user talk page to make the notification go away - one click only. This is not perfect, because if i received several messages, i may miss them. But if i received only one message, which is a very frequent scenario, having to click once more is quite annoying.

A good middle ground is to have it behave like Google Reader - if the unread message is scrolled into the viewable part of the browser, it should become read.

I should also mention that for many years all email clients marked the email as read immediately after the user viewed it or a few seconds later.

I understand that it may take time to implement it, but you should at least leave it as an enhancement.

I am reopening it as an enhancement.

Brandon, can you take a look?

Another similar issue: when I click on Reply, I obviously have read that message and don't need to make extra click to mark it as read.

Maybe the button should say "Remove" or something along these lines, instead of refer to read or not read.

There are many posts that I have read and still I want to keep in my list of messages to reply later. If they disappear automatically because I have read them then I will have a harder time finding them a couple of days later.

Keeping threads after replying is an even more peculiar case, agreed. If the button would say "Remove" then the behavior would be at least consistent and less confusing. Considering the little resources we have to update LQT maybe this is the most feasible solution to move this 2010 request forward...

Related URL: https://gerrit.wikimedia.org/r/57931 (Gerrit Change I8f3bf198b8948c5b2db63189c7784b7812e3247a)

I made a change for the messages but we do need a better way to settle this.

On the first point, I disagree with relabelling the button away from "mark as read"; this is a confusing change, which, though it does describe what the code does, isn't what users would expect.

More widely, the "solution" would be to auto-mark as read, and then have a persistent "read messages" list that a user could page through in some manner - i.e., a view onto the LQT threads of all the pages the user has watchlist-ed, sorted by time, grouped by page or whatever. But this feels like it could be a very expensive DB operation - thoughts?