abiosant@ : Thanks for the report.I have tried the issue following the below steps on Mac 10.11.5 and Stable 54.0.2809.0.

Steps:
=====
1> Load the extension
2> Login using facebook account
3> followed few games
4> After some time got 1 notification and clicked on it(watch/go to page)
  4.1> When clicked on watch opened one tab, when clicked again opened another tab(same as previous tab).Similar observation when clicked on Go to page.
  4.2> The above steps performed on the same notification until the notification pop-up was vanished.
5> Another Notification came after some more time and observed same behavior as seen for 1st notification.

Could you please help understanding the issue further.
And waiting for the notifications takes much of our time, it would be better if you have any jsfiddle/sample url to replicate it in easier way.

This most likely is an issue with your extension. I see that you have the following flow:

   1) When receiving a message from GCM, parse the data, store |data.id| as the stringified notification Id. (background.js:178)
   2) Create the notification passing in this |id|. (background.js:235)
   3) Attach a listener for onButtonClicked events *for each shown notification*. (background.js:247)

The number of log messages displayed (background.js:248) is going to grow linearly to the number of shown notifications because you keep attaching listeners. That's not great.

My gut feel would be that the |data.id| value in your GCM message is set to the same value, which means that this listener gets the same |nid| every time, thus creating a number of new tabs depending on the number of received notifications as well.

Hi, thanks for looking into the issue.

The problem does not appear if you click the same notification multiple times (that will only open new tabs as expected) but rather when you click different notifications over time. That is when the number of tabs opened per click start to stack up. If you click new notification only once, you will see that for every new notification that you receive, additional identical tabs will open.

See this example where I get 4 and then 5 notifications from only clicking the notification once (corresponding to the 4th and 5th time I click the notification) https://puu.sh/qgbP6/d2a15988d8.gif

I don't think any jsfiddle/sample url will help in this case, but if you give me your facebook name I can push test notifications to your extension.

Yes, that's why I suggested that you may be sending the notifications with the same |data.id| value. Because you attach a listener each time a notification is created, that would trigger exactly this behaviour.

Could you verify that each notification you send has a unique value in its |data.id| payload?

Hi sorry, didn't see your first answer. 

I will double check our IDs but the IDs/notifications we primarily send are for matches that go live (and of those have unique IDs) and when streamers go live (and their ID will be unique to them self but remain the same each time they go live) ..and we have the issue with both match and stream notifications. 

As far as we understand it from the documentation, if a notification has the same ID as a previous one, the previous is deleted in favour for the new one:
"If it matches an existing notification, this method first clears that notification before proceeding with the create operation."

Thank you for providing more feedback. Adding requester "durga.behera@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

abiosant@ : Could you please update further based on comment # 5 & 6 to further triage it.

Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot