11

The inbox used to visually mark an item as read when I use my middle mouse button to open the item in a new tab. It no longer does this. It does recognize that I clicked it and mark the notification as read, but requires me to click the refresh button for that to be visually rendered in the current tab. I assume this is a bug. If that assumption is right, please fix this.

I wonder if this has any connection to I'm clicking the same message multiple times to get it to clear, is it broken, or is something else happening? getting completed (apparently it's done and staff response is just pending).

Example of the behavior: Before clicking, there are three unread notifications indicated by the notification bubble.

The summary inbox dropdown with one unread notification visible. The notification bubble indicates three unread notifications in total.

After middle-clicking or right-clicking and opening in new tab on the notification, the unread counter has decreased as intended, but the notification itself is still styled as though unread.

The summary inbox dropdown with one unread notification visible. The notification bubble indicates to unread notifications in total. The visible notification should be styled as though read, but is not.

Improve this question
14
  • 1
    Same happens with Ctrl+Left clicking. It's not specific to middle clicking alone. Right click + "Open in new tab" does not mark anything as read (which is consistent as before, even if undesirable).
    – VLAZ
    Commented Jul 2, 2024 at 15:22
  • 1
    OK, as extra information middle click and also Ctrl+left click both reduce the counter - if you had 3 unread message, you go down to 2. But the message in the inbox still stays the same
    – VLAZ
    Commented Jul 2, 2024 at 15:26
  • 1
    Note that the previous implementation of this was broken, and would frequently mark the notification read without actually opening it (I suspect due to triggering on mousedown rather than the link actually being activated).
    – Ryan M
    Commented Jul 3, 2024 at 1:40
  • @RyanM yes, previously it was marking on mousedown. So, if you click that also initiated loading the new page and sending the request to mark the message as done. The reload might happen before or after the request to the backend finished, so some times simply left-clicking once might or might not mark the notification as read. You could work around it by clicking and holding - that'd trigger the mousedown and send the request and also mark the notification as read. But wouldn't initiate the navigation until you released the mouse. It's how it used to work.
    – VLAZ
    Commented Jul 3, 2024 at 9:30
  • Now it's not even attempting to mark the notification as read, it seems. It only sends notification via the beacon API (which solves issues with sending a request and navigating away at the same time).
    – VLAZ
    Commented Jul 3, 2024 at 9:30
  • 1
    This report is appreciated. There are various ways that users can interact with inbox notifications and we'd like to do a holistic review with the UX team on the desired behavior before embarking on further changes, so that it doesn't become a game of whack-a-mole fixes.
    – Berthold StaffMod
    Commented Jul 5, 2024 at 22:46
  • @Berthold Maybe you could also consider stackapps.com/questions/5059/… for your review of the topic
    – samcarter_is_at_topanswers.xyz
    Commented Jul 5, 2024 at 22:58
  • I genuinely wonder- how hard can this be? if the user requests a resource with the same URL as an unread item in their inbox, mark that item (and potentially other related unread items) as read. if that's unacceptable for performance reasons, then fine, but that seems like the simplest, most robust way to implement it from a naive perspective.
    – starball
    Commented Jul 5, 2024 at 23:18
  • 1
    @Berthold same as it was before the bug started: middle click used to mark the item as read, without having to click the refresh button.
    – user152859
    Commented Jul 6, 2024 at 6:47
  • 2
    @samcarter_is_at_topanswers.xyz That's an interesting addition to the holistic review, I have passed that along!
    – Berthold StaffMod
    Commented Jul 8, 2024 at 18:06
  • It doesn't seem like this can be reproduced any longer- mostly. The notification bubble (1) is cleared by middle clicking, even on other tabs you have open. The only note is that the appearance of the notification in the inbox remains as though it is unread in the tab you just opened the notification from.
    – Frog StaffMod
    Commented Apr 4 at 19:55
  • 6
    @Frog "The only note is that the appearance of the notification in the inbox remains as though it is unread in the tab you just opened the notification from." yes and that is the problem. Middle-clicking used to mark the notification as read, which is what the bug is about. Without this behaviour is exceptionally annoying to deal with multiple notifications, as there is no indication which ones you've viewed or not. Note that this was an explicit feature in the inbox redesign. It's definitely still reproducible. The count wasn't the bug.
    – VLAZ
    Commented Apr 4 at 22:17
  • 2
    @Frog the bug arose from somebody fixing a different thing related to the count. And apparently completely went back on the original design where (almost) any way of opening new tab with notification would mark it as read in the current view. But there was no count bug on opening notifications in a new tab. The bug was left-clicking, i.e., opening the notification in the current tab. And that still is inconsistently marking the count on reload. So it's not even fixed. It only somewhat reduced the frequency but also regressed other functionality.
    – VLAZ
    Commented Apr 4 at 22:21
  • 2
    @VLAZ Got it- I misunderstood the bug in the first place, then. My bad! I've edited the issue to clarify.
    – Frog StaffMod
    Commented Apr 8 at 15:42

0

Reset to default

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.