1568769 - "Open Link in new tab" for issue doesn't set marker as read on Github notifications page

Status: RESOLVED INVALID

(Web Compatibility :: Site Reports, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Firefox/70.0 ID:20190721215935

I'm using the Github notification page to go through the unread messages of issues and PRs: https://github.com/notifications.

Using the left mouse button even in combination with the meta key, the underlying issue/PR gets marked as read. But when I'm using the context menu and select "Open Link in new tab" the issue/PR isn't marked as read.

I'm not fully sure but I think that this is a regression.

Comment 1

[Cristian Fogel [:cfogel]]

Trying to get the regression range for this issue but .... apparently it doesn't reproduce with the current nightly build 70.0a1(2019-08-04) 201908421813 - with a macOS 10.14.
Checked with just issues for now.

Does the issue still manifest?

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Ok, so it actually gets marked as read, which I can see after reloading the page, and the entry being not present anymore. But the check which is displayed at the end of the line is still not getting replaced with the dot (which indicates that the message is marked as read).

Comment 3

[Cristian Fogel [:cfogel]]

Attachment: gitChecks.gif

Posting a recording from a Windows OS, but the same scenario and behavior is displayed for the macOS device.
Is there anything else that I might be missing?

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I don't know. I also tested with a fresh profile, which exhibits the exact same behavior with latest Nightly. Also going back to Firefox 60ESR I still see it. So not sure what actually has been changed for my case. The 2nd screen, and external mouse don't influence that too.

Comment 6

[Cristian Fogel [:cfogel]]

The same behavior seems to be on Chrome as well.
The status is updated only after (In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #2)

But the check which is displayed at the end of the line is still not getting replaced with the dot (which indicates that the message is marked as read).

Just to confirm, the checkmark is updated when you open the Read section?
From what I see the same behavior is present on Chrome as well so it might just be a change on Github's side.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Not sure what you mean with "Read section". But it is updated when I do a normal left click, or a Cmd+Click on the item.

Might be a webcompat issue, yes. So moving it over to the appropriate component for further investigation.

Comment 8

[Cristian Fogel [:cfogel]]

In the Notifications tab, there is the Unread/Read "section".

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Again, and as mentioned in comment 2 the entries which have been opened will disappear after a reload or clicking any link (which basically is a page load).

Comment 10

[Dennis Schubert [:denschub]]

I can reproduce this in Chrome, Safari, and Edge as well. This makes sense, as they only update the "read" status on click via the global click listener in the document. When using the context menu, the link is not clicked, and we don't send a click event. But that's expected, and I don't think we ever did?

Given that this behavior is consistent in all browsers, this does not seem like a WebCompat issue (which it would be if it would have differently in Firefox compared to other browsers), and I honestly don't think it's an issue at all. It's just the way GitHub designed their implementation. Because of that, I'm going to close this. However, feel free to reopen if someone has a different opinion. :)

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Ok, Thanks! So I just sent a request via the github support page instead. Maybe this could be made working this way. Lets see...