[Chrome] Notification Center can attribute notifications to incorrect application when applications are nested

Number:rdar://FB9292033 Date Originated:2021-07-08
Status:Open Resolved:
Product:macOS/Notification Center Product Version:11.4 20F71, 12.0db2 21A5268h
Classification:Incorrect/Unexpected Behavior Reproducible:Sometimes
Background: Google Chrome presents both banner-style and alert-style notifications. The alert-style notifications are delivered through a specific helper .app nested within Google Chrome.app. For the purposes of this bug report, I’m working with the Google Chrome Canary, our nightly build, so I will refer to it as Google Chrome[ Canary], as an indication that I’m using the canary but the bug will manifest equally even in the ordinary stable version of Chrome. The two sources of notifications are, in version 93.0.4568.0:

Google Chrome[ Canary].app
Google Chrome[ Canary].app/Contents/Frameworks/Google Chrome Framework.framework/Versions/93.0.4568.0/Helpers/Google Chrome Helper (Alerts).app

Alerts produced by both of these .apps are ordinarily attributed in the Notification Center to the outermost .app, using its name (such as Google Chrome[ Canary]) and icon. This is correct and expected.

Under some circumstances, alerts produced by the inner Google Chrome Helper (Alerts).app are attributed to Google Chrome Helper (Alerts) rather than Google Chrome[ Canary], and instead of showing the proper icon, show a grayed-out version with a prohibitory sign superimposed. This is incorrect and unexpected.

It appears that this occurs when the first notification (or request for notification permission) from the inner Google Chrome Helper (Alerts) occurs before Launch Services has had an opportunity to fully register the entire Google Chrome[ Canary].app. This is most likely to occur following a fresh installation of Chrome, as Chrome currently requests notification permission fairly early during startup, and this request may race Launch Services database registration of the entire .app bundle.

Steps to reproduce:

Run these commands to revoke any notification approvals for Chrome, and to reset the Launch Services database.

% defaults delete com.apple.ncprefs
% killall -TERM usernoted
% /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill

Then, launch Chrome. For this test, I am using Google Chrome Canary, from https://www.google.com/chrome/canary/, installed in /Applications. For this test, it’s not relevant that Chrome has already been installed and that it’s saved data in ~/Library/{Application Support,Caches,Preferences}.

Expected behavior:

Chrome should start, and because notification permission had been revoked, the OS should show two notifications requesting this permission. One is associated with banners, and the other with alerts. Both of these notifications should attribute “Google Chrome[ Canary]” and should use that product’s proper icon, not grayed out, and without any prohibitory sign superimposed. Assuming permission to notify is granted notifications subsequently raised by Chrome will also be attributed properly to “Google Chrome[ Canary]” and will use the proper icon.

Observed behavior:

On occasion, Chrome starts, and the OS shows two notifications requesting permission for Chrome to notify. The notification associated with banners will be displayed correctly. The notification associated with alerts will be attributed to “Google Chrome Helper (Alerts)” instead of “Google Chrome[ Canary]”, and that notification’s icon will be grayed out with a prohibitory sign superimposed. Assuming permission to issue alert-type notifications is granted, alert-type notifications subsequently raised by Chrome will also be attributed to “Google Chrome Helper (Alerts)” and will use the wrong icon. The attached screen shot (https://bugs.chromium.org/p/chromium/issues/attachment?aid=509974&signed_aid=Ti45WLNnadOVzQjDd775NA==) shows a demonstration of this problem.

(Note: to test notifications raised by Chrome, it is possible to use https://tests.rknoll.at/. The site must be granted permission to notify from within Chrome when visited. With the “Req. interaction” checkbox checked, Chrome will raise an alert-type notification when “Display the notification” is checked.)

The incorrect attribution persists as long as NotificationCenter (/System/Library/CoreServices/NotificationCenter.app) remains running. “killall -TERM NotificationCenter” causes the notifications to be dismissed, and assuming a fairly immediate restart (as is typical), they will be redisplayed correctly: those that had the wrong icon and attribution will be corrected on NotificationCenter relaunch, assuming the LaunchServices database is correct at that time. This is effective both for notifications offered by Chrome and the OS-provided notifications requesting permission to notify. Accordingly, this is also self-healing upon reboot (or re-login): attribution returns to the proper .app, and the correct icon is displayed, after a reboot.

As the bug involves a race against Launch Services registration, I have found that certain conditions alter the likelihood of experiencing it. It is more likely to occur with the universal (x86_64-and-arm64) version of Chrome that we ship to arm64 Macs, likely because it’s heavier than the x86_64-only version that we ship to x86_64 Macs, causing registration to take longer. Although it’s possible to trigger the bug on a Mac of any CPU architecture, using the universal version on x86_64 seems to produce a higher likelihood of reproduction than using the x86_64-only version.

I have experienced this bug on:

macOS 12.0db2 21A5268h on arm64
macOS 11.4 20F71 on x86_64
macOS 12.0db2 21A5268h on an x86_64 virtual machine
macOS 11.4 20F71 on an x86_64 virtual machine

Originally reported at https://crbug.com/1227370.


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!