Last modified: 2014-01-17 03:55:31 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T25031, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 23031 - LQT messages should become read without having to click "Mark as read"
LQT messages should become read without having to click "Mark as read"
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
LiquidThreads (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-03 12:50 UTC by Amir E. Aharoni
Modified: 2014-01-17 03:55 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Amir E. Aharoni 2010-04-03 12:50:23 UTC
This happens in TranslateWiki. Special:Version there says "Version 2.0-alpha r64515".

Message only becomes read after i click the "Mark as read" button. I would expect that it would be automatically marked as read after i view it, but it stays unread even after i reply to it.

See also: http://translatewiki.net/wiki/Thread:Support/Messages_stay_unread
Comment 1 Andrew Garrett 2010-04-06 00:22:39 UTC
This is intended behaviour.
Comment 2 Amir E. Aharoni 2010-04-06 18:21:26 UTC
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.
Comment 3 Amir E. Aharoni 2010-06-24 07:18:35 UTC
I am reopening it as an enhancement.
Comment 4 Max Semenik 2010-09-20 12:25:29 UTC
Brandon, can you take a look?
Comment 5 Max Semenik 2010-09-20 12:27:19 UTC
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.
Comment 6 Quim Gil 2013-03-21 07:20:16 UTC
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...
Comment 7 Gerrit Notification Bot 2013-04-07 18:06:58 UTC
Related URL: https://gerrit.wikimedia.org/r/57931 (Gerrit Change I8f3bf198b8948c5b2db63189c7784b7812e3247a)
Comment 8 Nischay Nahata 2013-04-07 18:18:02 UTC
I made a change for the messages but we do need a better way to settle this.
Comment 9 James Forrester 2013-04-08 16:10:54 UTC
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?

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links