Issue metadata
Sign in to add a comment
|
Clicking on Whatsapp web notification opens a new tab instead of going to the already open one
Reported by
andrea.d...@gmail.com,
Sep 27
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 Steps to reproduce the problem: 1. Open WhatsApp web 2. Receive a message (when notification are enabled) 3. Click on the notification pop-up What is the expected behavior? Chrome should "move" to the already open WA tab. What went wrong? It actually opens a new tab (https://web.whatsapp.com). Did this work before? Yes Before today's update. Can't point at the right version but it was this update. Chrome version: 69.0.3497.100 Channel: stable OS Version: 16.04 Flash Version:
,
Sep 28
Thanks for filing the issue! Unable to reproduce the issue on reported chrome version 69.0.3497.100 using Ubuntu 14.04 with the below mentioned steps. 1. Launched Chrome 2. Navigated to https://web.whatsapp.com 3. Enabled notifications -> moved to other tab 4. Clicked on the notification pop-up We observed the message getting opened in already opened web whatsapp page, rather than opening it in a new tab. @Reporter: Could you please check the same on a new profile without any apps & extensions and let us know if the issue still persists. Any further inputs from your end may be helpful.
,
Sep 28
As a matter of fact I cannot reproduce the bug consistently. It has not happened yet today and after filing the issue it has happened ~10% of the times (despite I consistently had it before opening the bug report). I am not sure what was causing it then, but it is indeed possible that it is linked to some interaction with extensions.
,
Sep 28
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 28
I have seen what appears to be related to this where the `tag` is used to replace notifications. I have created an example based on the mozilla example code for this feature which reproduces this consistently. https://github.com/ukcrpb6/chrome-notification-test/blob/master/public/index.html Here if the tagged variant which issues a single notification will cause a new tab to be created, as if the notification is orphaned, whereas the non-tagged variant behaves as expected. MacOS High Sierra - Chrome Version 69.0.3497.100 (Official Build) (64-bit)
,
Oct 1
As per comment#3 by reporter the issue seems to be very inconsistent and we could not reproduce it from our end, hence removing Needs-Bisect label and requesting someone from "UI>Notifications" team to have a look into this and help in further triaging it. @Reporter: Requesting you to check the same in a new profile without any apps & extensions and let us know if this is still an issue. @rpb6: Providing a sample test file would be more helpful, to triage this further. Thanks!
,
Oct 1
Unfortunately, this has happened only once in the last 3 days, so not much to add on top of comment #3. For what I could test, the error did not appear without extensions & apps, but again it does not happen often at all. I am sorry but I cannot be more helpful to debug this.
,
Oct 1
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 3
From c#3 the issue isn't consistent and it is clear that the issue doesn't happen in a clean profile, hence closing this issue and marking it as Won't fix. @Reporter: Please feel free to file a new request/issue, if this is seen again. Thanks!
,
Oct 27
New issue filled as https://crbug.com/898486 Did bisect and found the suspect commit, since this is a regression bug, maybe we should fix it as soon as possible, also need to clarify that this issue affects all user, even a clean profile |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by vamshi.kommuri@chromium.org
, Sep 27