Is "Mark items as read on click/middle click of external links" deprecated?

[Sevichecc]

In the latest version of Miniflux, when users click the external link button, the entry is no longer marked as read automatically as it was before. Is this change a result of a deliberate refactor or is it potentially a bug?

[xfzv]

Works as expected with bcbf9f4 here (and I've run 2.1.4 at some point too but never had this issue) so I think it's probably a bug on your end.

[SansGuidon]

Maybe a side effect of the latest update of Miniflux that introduced the feat: mark media as read when playback reaches 90% and hence changed the list of preferences for when to mark an entry as read ?

I've noticed that my default preference were changed after the update of Miniflux, I was automatically opted out of "Automatically mark entries as read when viewed" and I was automatically opt in with "Mark entries as read manually".

If I'm not mistaken, it's a side effect of the update, but I wonder if it's the same for you @Sevichecc . What are your current Reader settings ?

[Sevichecc]

@SansGuidon I've tried all possible prefrence settings, but the problem persists. My Miniflux version is v2.2.0. I plan to install a fresh Miniflux instance on my newly set up VPS to see if it works as expected. The issue might be related to my current machine configuration.

[ztec]

@Sevichecc I was not aware of such feature. Are you sure it was an expected behavior previously ?

I quickly tested with an old version of miniflux and I have the following behavior:

• (1) when "Automatically mark entries as read when viewed" is checked article are marked as read as soon as I display the miniflux entry page. If I manually unread the article and click the external link, it mark it as read again
• (2) when "Automatically mark entries as read when viewed" is NOT checked, article is never marked as read. Neither on display in miniflux or by clicking the externalLink to open it.

With the new 2.2.0, I've done tests with the new options and I get behavior (1) when I select Automatically mark entries as read when viewed or Mark entries as read when viewed. For audio/video, mark as read at 90% completion. But not the other two.
From my point of view, the feature behavior did not change at all, and the new options did not interfere with it.

@SansGuidon the feat: mark media as read when playback reaches 90% should not change anything regarding your previous options. At the same time of the previous tests I mentioned, I checked whether the options selected changed and the behavior was the one expected. Basically two options are expected (and happened in my tests):

• "Automatically mark entries as read when viewed" checked will get you the Automatically mark entries as read when viewed selected. The same as before
• "Automatically mark entries as read when viewed" unchecked will get you the "Mark entries as read manually" selected. The same as before.

The two other options cannot be selected by default. That not the intended behavior anyway. I need to do more thorough tests on that to be sure on my side I did, and the option checked always convert into Automatically mark entries as read when viewed in my test environment. (2.1.4 upgraded to 2.2.0 with the database migration between the two)

ps, I made the feat: mark media as read when playback reaches 90% change so I'm willing to investigate and fix anything I did wrong.

[Sevichecc]

@ztec @SansGuidon Recently, I transitioned from a Chromium-based browser to Firefox and discovered that the "Mark items as read on click/middle click of external links" feature works on Firefox (Developer Edition v.131.0b9) but not on Chromium-based browsers (tested on Brave v.1.70.117 and Chrome Canary v.131.0.6733.0).

When investigating using the browser's developer tools, specifically in the Network tab, I found that the POST request to https://${miniflux_instance}/entry/status is not triggered in Chromium-based browsers. This leads me to believe that the issue might be related to changes in browser behavior rather than Miniflux itself.

Could this difference in browser behavior possibly explain the inconsistency we're seeing? I'd appreciate your thoughts on this observation.