OK this thing is bugging me daily so raising a thread about it.

The notifications popup that we have, why does it have to mark all the five visible comments as read when you keep it open for a few seconds? This is just really frustrating as the notifications themselves don’t give any clue what the target post is, so after they are all marked read, I have to click through all of them even if they would all concern only a few posts.

Also, why just 5? I would love to have it scrollable, so I can read my notifications from the menu and they would be only marked read when I have seen the actual post in question.

This is how Facebook works and tbh it’s fantastic :slight_smile:

Do people like the way it is or can I make an attempt to change it?

Note: This discussion was imported from Loomio. Click here to view the original discussion.

Oh yeah! I totally agree. It would be great if the popup had more information so you don’t have to click all items just to find out the next refers to the previous you’ve already viewed.
Scrollable is okay, but I don’t miss it. When I want to see more, I just click ‘view all’.

The mobile notifications actually work really well, though more information about the post in question would be great.

Definitely yes to the first point. It’s something which bugs me as well. Marking notifications as read should happen only by hovering over or clicking on the individual notification, not en masse a few seconds after the popup pane has been opened, as happens at the moment.

As to the second, I certainly wouldn’t object to the pane being scrollable, but it doesn’t bother me the way it is. It’s easy enough to click ‘View all’, and in any case I suspect that for the majority of users, it would be rare for there to be more than 5 unread notifications when they check in. I can’t see a downside of making the pane scrollable, but it’s not as high a priority for me as changing the behaviour of ‘marked as read’.

@jellelangbroek, there is a user Javascript which appends the post title to each notification in the list. It would be great if someone could adapt this for the main Diaspora code base. See

@goob cool userscript - would definitely prefer that way than how it is at the moment - might take a hack at it :slight_smile: I’ve grown to dislike any kind of page modifying scripts and as diaspora is open source better just modify the code itself :wink:

Yes, @jasonrobinson if you (or someone) can do that, it would be fantastic. I think Deus Figendi writes those add-on scripts because that’s the code he’s comfortable working with.

I assume he’s happy for anyone to modify his code, but would be worth checking to make sure before working on it.

I don’t think the pane needs to be scrollable but please do remove this annoying feature that marks the notifications as read.

Great that there seems to be annoyance with the automarkread thing in not just me :stuck_out_tongue:

@goob I don’t think it’s realistic to use an external user script code for internal diaspora code as is - so no problems :slight_smile: For example, looking at this piece of code, it makes extra ajax requests to fetch the post data for the notifications. Of course this would not be necessary if the data was built in for rendering.

Cool, I didn’t know how much it would have to be adapted, or even whether you’d have to start from scratch - I just linked to it in case it gives any ways in to coding something for the main code base. I’ll leave it in your capable hands!

agree with @jasonrobinson , have a scrollable notification.

Have just opened the notifications pane and watched what happens, and the five notifications don’t quite get read as marked all en masse. Some notifications at least went from unread to read individually, as the cursor is moved around, but once one gets marked as read, the others seem to follow very quickly. So it seems the code already does recognise cursor behaviour and takes each notification as separate, but perhaps the amount of time the cursor needs to be left over each notification before it gets marked as read needs to be increased.

I think the most important point is to mark as read notifications when we open a post in the single post view. Even if the user doesn’t touch to the notification panel or page.

Proposal: What should be default when fixing #4810?

There is a fix for the notifications being marked read when the notifications menu is opened that already has working code. Due to feedback, there will be a user setting made to control whether the notifications should be marked as read without actually reading them.

In other words, this setting will control whether to have it work like it works now (notifications are marked read 2s after opening the notifications dropdown) - or not mark them read automatically at all, unless user visits post/action in question.

This vote is ONLY about this setting and ONLY about which should be default - current behaviour or new behaviour.

YES - if you want to keep the current behaviour as default
NO - if you want the new behaviour to be default

The github issue is here:

Outcome: If #4810 functionality is merged in - the NEW functionality should be default in the user settings.


  • Yes: 0
  • Abstain: 3
  • No: 23
  • Block: 0

Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.

I read Ruxton’s comment as warning against making a change which might break code/functionality for users. If this is not a danger/possibility, I would be happy to see the notification behaviour changed. But I’d like that clarified before voting.

@morgenstern you can see a preview of how this would work in @steffenvanbergerem’s video here:

I think that’s quite intuitive.

@goob The code I used for the video has not been pushed to the branch and I think I lost the code. However, rewriting that shouldn’t be a lot of work.

I read Ruxton’s comment as warning against making a change which might break code/functionality for users. If this is not a danger/possibility, I would be happy to see the notification behaviour changed. But I’d like that clarified before voting.

I think Ruxton meant was not break code, but change functionality. YES keeps current functionality as default, NO changes it.

@steffenvanbergerem Oh, thanks for the clarification. I thought your video was to show me that this is how your PR will work if implemented. I could only vote for a change of functionality if it worked in the way shown in the video. If you could please clarify whether or not the functionality shown in your video would be implemented with your PR, that would help me decide how to vote on this proposal.

When I say ‘like in the video’ I mean that there needs to be a means of marking individual notifications as read in the notifications drop-down itself without clicking on a notification to be taken to that post or clicking ‘view all’ to go to the notifications page.

If this were the case, I don’t think we’d need to build an option to choose between this and the current system - just change it to work in this way (which is far better, I think).

@goob I won’t be able to add the user setting so I won’t be able to finish my PR. Right now you can click on the notification and you won’t be taken to that post. This is only the case when you click on the “post” link.

I can work on my PR again and create a similar user experience to the one you see in the video. However, like I said we still need someone to finish the PR.