Skip to main content

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

18
  • 2
    Sorry to hear that it hasn't been working for you. But...clicking the message opens it and marks it as read. Clicking the envelope marks it as read without opening it. If this is not working for you, then there is a local error with the execution of the script for you. Please give your browser version, etc (as it works fine for me on all browsers where I try it). The only type of "open" action that right now wont mark it as read is "right click > open in new tab". But middle click or ctrl-click should mark it as read while opening it on a new tab. Commented Dec 4, 2022 at 19:12
  • @YaakovEllis - I'm on Mac Mojave, Safari 14.1.4 [which I'm aware is technically out of date]. I always 'open in new tab', never click though in the same tab, so I guess that's the bug I'm hitting. I just tried variants on a theme of 'open' & as far as I can see, only 'send my current tab to the new URL' dismisses the message & header count. I only had one message - yours above - in the queue when I tried that. Commented Dec 4, 2022 at 19:20
  • 2
    Our challenge with handling "right click > open in a new tab" is that there is no way in the browser (that we were able to discover) to know that this is what you did after you right-clicked. We were left with either "every right click marks as read, no matter what you did (or even if you did nothing)", or "right click does not at all mark as read". Commented Dec 4, 2022 at 19:22
  • 2
    Now - someone else above complained about the same thing - that this is their primary way to mark as read (this being the only option on many tablets). And it is something that we have to consider - whether it is fair to users to mark as read for any right-click. Commented Dec 4, 2022 at 19:23
  • 1
    We are also considering trying to address this (though not right away) with functionality that would mark all inbox items read relating to the question/answer being opened (and preferably also indicate on-screen what the previously-unread items had been). This feels like a superior solution to me as it doesn't require guessing the intention of the reader on a right-click, and also takes care of all related inbox items at the same time. But it will have to wait it's turn for implementation. Commented Dec 4, 2022 at 19:25
  • I'm not 'technically' right clicking. I'm using a 3rd party mouse with a non-standard button config, but what it's actually sending to the OS is as though I Cmd/clicked a link. This in itself is a 'valid' macOS/Safari command, set in prefs as 'open link in new tab'. I'm aware that feels like it adds complexity, but I have tested a true Cmd/click & the behaviour is identical. Commented Dec 4, 2022 at 19:26
  • 1
    One usage pattern that is now possible that I have tried and often use now, is to just have one tab open. Open the inbox, click on an item, it loads in the same tab and is marked as read. You no longer have to open up lots of other tabs (since the inbox marks all the messages as read right away, and this is the way to use it). You can go one by one. Commented Dec 4, 2022 at 19:26
  • 1
    "I have tested a true Cmd/click & the behaviour is identical" - then this is probably a quirk with your particular browser. In all that I have tested, ctrl-click marks it as read. Disclaimer: I develop on a windows machine, and ever since Apple stopped offering Safari on Windows, I have had no way to test Safari (though others on the team can do so , and I'll try to enlist their help on this when we are able to get to it). Commented Dec 4, 2022 at 19:28
  • I appreciate it's a potential working method - but years of habit have nbeen that if I have a tab, it needs my attention - maybe now, maybe tomorrow; but I do cycle through them to see if they have any unannounced activity, which they often do. It's become a simple 'Open I want to know, closed, fugettaboudit' with the very occasional 'following' for something I feel may move long term, but not this week. Commented Dec 4, 2022 at 19:30
  • @YaakovEllis - [sorry, keep forgetting to tag you] Mac does't use ctrl/click except to open the contextual menu [an alternative to right click for those used to trackpads] so it's not something I can test on this platform. Also, no middle click [which I think is a nix thing? can't test]. --- Lemme just jump onto this from Chrome [whilst holding up garlic & religious symbols;) … OK, that behaves differently… but not enough to persuade me to ever use it, sorry:\ So, it appears something is non-standard, but I don't have the expertise to tell what. Commented Dec 4, 2022 at 19:39
  • @YaakovEllis Have you considered adding some parameter to the url as suggested by VLAZ in this comment meta.stackexchange.com/questions/384148/… ? Commented Dec 4, 2022 at 19:40
  • 2
    This is starting to feel like the 'Tested with Internet Explorer' days :\ Commented Dec 4, 2022 at 19:40
  • 1
    @Tetsujin, ahem: "I'm on Mac Mojave, Safari 14.1.4 [which I'm aware is technically out of date]. We do test on the browsers that we support. Commented Dec 4, 2022 at 19:46
  • 1
    @samcarter_is_at_topanswers.xyz adding a parameter is something else that we are considering. We would prefer not to as historically we have tried to avoid this, as it can leak into other things (even if we clear the param on the client or through a redirect). But is is another option. Commented Dec 4, 2022 at 19:48
  • 2
    @Tetsujin anyway - even though your browser is not supported, it is still a scenario that we would like to support. I appreciate your trying it out and taking the time to give feedback. And hope that we will eventually be able to have it addressed to your liking. Commented Dec 4, 2022 at 19:53