New issue
Advanced search Search tips

Issue 825497 link

Starred by 7 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Chrome Notification API (for Extensions!) Cannot Re-enable Once Blocked

Reported by collin.c...@blueprairie.com, Mar 24 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3377.1 Safari/537.36

Steps to reproduce the problem:
1. Install and grant extension permissions including desktop nofifications

Example notification: https://i.imgur.com/JLn9y1c.png

2. Click "block all notifications from this app" once on a notification from the extension

Example:  https://i.imgur.com/f7Rp0B1.png

3. User now has no way to ever re-enable desktop notifications for this extension as it is not exposed in sites etc.

*Actual notifications are not even being blocked in my testing, instead the messages are now send using ugly javascript messages in center of the screen as shown here in this Tampermonkey test (unless they are just detecting now denied notify perms and sending the same message this way themselves):  

Example: https://i.imgur.com/yR31pos.png

What is the expected behavior?
Allow user to re-enable previously blocked/denied desktop notifications for extensions

What went wrong?
Once user blocks/denies (ie by accident etc.) any Chrome extensions' desktop notification, the user never again currently has any method to re-enable.

Did this work before? N/A 

Chrome version: 67.0.3377.1  Channel: dev
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: 

Either the "chrome-extensions://" needs to be allowed/listed/exposed in the new notifications world of Chrome>65 to allow full user control of not only sites notifications, but their extensions, or another GUI (and for enterprises documented policy/config files/etc.)

I also find no programatic method on the back-end for an extension DEV to even detect using PermissionLevel query and then prompt the user to give them a chance to re-enable, as it appears that once the user blocks the thought was to err on the side of protecting from malware (makes sense) but this also now means the DEV's 2nd+ attempts to fix it from the back-end are impossible due to an immediate DENIED return value on the attempt.  May want to re-think introducing a DEV method to at least re-prompt the user as there are other scenarios I can think of that app-specific features may be further limited by a users' prior notification-blocking decision, and as a DEV I would want to remind the user that app functions are limited and give them another chance to unlock all functionality by changing their mind, etc.
 

Comment 1 by ajha@chromium.org, Mar 26 2018

Labels: Needs-Triage-M67
Can you confirm if there is even a current workaround for this?  I did manage to paste the chrome-extension://dhdgffkkebhmkfjojejmpbldmpobfkfo and very surprisingly it did resolve it and change it to the friendly app name in this case of "Tampermonkey" with the extension logo in the defined sites settings (I had never tried forcing an extension ID there) but no matter what I do to try to manually set the notifications permission to allow there, it does not seem to have any impact in this case and again allow the blocked extension to again send the desktop notifications through.

So, depending on how much is perhaps just not wired to handle extensions in sites settings GUI, at least SOME of it does appear to be wired as of now to at least give the impression that perhaps the possibility of using the same "sites" method to handle extension notifications may actually be a viable option.
Is it just me or is this not a pretty visible UI bug when it is just impossible to re-enable and turn notifications back on for ANY/ALL chrome extensions?

It may sound trivial to state that full removal of an extension and wipe of it's settings to then re-install is an acceptable method to re-enable their notifications, but in the case of extensions with large amount of stored data (without even also thinking about Chrome sync issues) this is simply not a realistic ask so hopefully this can at least be acknowledged as a reproducible bug and addressed sooner rather than later.

TIA for hopefully getting this triaged soon!

Comment 4 by ajha@chromium.org, May 11 2018

Cc: phanindra.mandapaka@chromium.org
Components: -UI UI>Notifications Platform>Extensions
Adding proper component for someone from the respective team to have a look into this. Phani@ to help with triage.
Labels: -Type-Bug -Pri-2 ReleaseBlock-Stable M-68 RegressedIn-63 Target-68 Triaged-ET FoundIn-68 OS-Linux OS-Mac Pri-1 Type-Bug-Regression
Owner: patricia...@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on reported latest dev 68.0.3423.2,Beta 67.0.3396.40  & on latest chrome 68.0.3429.0 using Windows 7 &10,Mac OS 10.13, Ubuntu 14.04. Hence providing bisect information below

Bisect Info:
================
Good build: 63.0.3220.0
Bad build: 63.0.3221.0

You are probably looking for a change made after 503076 (known good), but no later than 503089 (first known bad).

CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/f9b4c77f094c17f529233ff29fc89bccdac48a3e..0601e5375167f5894c2ffa22b81e7a6528637579

suspect: https://chromium.googlesource.com/chromium/src/+/0601e5375167f5894c2ffa22b81e7a6528637579

Reviewed-on: https://chromium-review.googlesource.com/662997

@patricialor: Please confirm the issue and help in re-assigning if it is not related to your change.

Thanks!

Comment 6 by peter@chromium.org, May 14 2018

Cc: peter@chromium.org patricia...@chromium.org dewittj@chromium.org
Labels: -ReleaseBlock-Stable
Owner: hwi@chromium.org
Yeah, this is not great.

Justin, do you recall whether extension settings continued to show up in chrome://settings/content/notifications when we removed the notification center from the desktop platforms? I *think* they did, but I can't find the discussions anymore.

Hwi, would you have an opinion on where to surface such a toggle? Content Settings never was an ideal place even if we included it there, and since there's now a "Details" page for items on chrome://extensions/ we could add a toggle there when the extension has the "notifications" permission. I've attached a rough mock of something that could work?

In either case, this doesn't have to block the stable release.
extension-details.png
59.7 KB View Download

Comment 7 by ajha@chromium.org, May 15 2018

Labels: hasbisect

Comment 8 by hwi@chromium.org, May 15 2018

Cc: jawag@chromium.org namratakannan@chromium.org
Owner: ----
Status: Available (was: Assigned)
c6:

+jawag (Extensions), +namratakannan (WebUI) - does c6 sound good to you? 

Adding the notification toggle below Permissions section SGTM (as shown on the mock on c6)

Peter, I can't remember exactly. I think all we showed were notifications exceptions for domains with hosted extensions that were granted notifications permission.

While the chrome://extensions page is convenient, it is not something we ever expect users to navigate to.  So if this is put there I'd hope there is a plan to also add a section to chrome://settings somewhere.
Guys this is awesome and I love that mockup showing it added to the extensions page.  I disagree very much with @dewittj I really think more folks than he thinks will find it there if they ever need it.  Reason is simple - only those who either have enough knowledge to know what they did and want to re-enable an extension's notifications, or the only others that would need it - those totally in the dark and going after that setting directly as instructed by some person or doc, anyway! :)

Any ETA on when we'll finally see this change live?  TIA!
Just checking if there is any update on the changes you proposed above.
I've spent 45 minutes looking for a way to reverse this... Neither the Content Settings or the Extension Settings pages seem to have any way to reverse this...

I accidentally disabled notifications for a plugin I absolutely need, and now there's no way to get it back... Can someone please update on the status of this issue?
Labels: Hotlist-DesktopUIChecked Hotlist-DesktopUIValid
***Mass UI Triage***

Adding labels for expert review.

Sign in to add a comment