John, would you mind taking a look at this?

I've put together a quick test case here:

https://gdnmobilelab.github.io/tests-for-google/action-tap-focus/

also attached.

Deleted: action-tap-focus.zip 1.3 KB

action-tap-focus.zip 1.3 KB Download

Looks like this happens because there's different shade-hiding behaviour for notification actions compared to normal notification clicks when they trigger an intent to start a broadcast - I was able to replicate this in a dummy app with a simple broadcast receiver that starts a blank activity.

The comment on this question confirms it occurs when using broadcasts instead of starting activities directly: http://stackoverflow.com/questions/18261969/clicking-android-notification-actions-does-not-close-notification-drawer?noredirect=1&lq=1 .

The fix won't be as trivial as the top answer there though (dismissing all system dialogs whenever a broadcast is received by the NotificationService), because for some actions we *want* to keep the notification drawer open, e.g. if the website uses notification actions for a quiz within the drawer.

I'm probably not going to get around to this anytime soon.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

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

Further to #3, the precise behaviour we'd like would be that whenever a service worker tells Chrome to open/focus a window in response to a notification click, Chrome should dismiss the notification shade if it's showing.

also re #3, I think I may have been a little misleading back in Aug '16 - Chrome actually sets a pending broadcast intent for *both* notification content intents and action button intents, so it must be Android treating these intents differently. If that's the case there may not be much we can do here.

Spoke to the Android team about this and they said it should work to send a 'CLOSE_ALL_SYSTEM_DIALOGS' intent to hide the shade, however this will also close all system dialogs and recents if showing.

(internal comment thread: https://docs.google.com/a/google.com/document/d/1DkZKAZjt0fqqdBdpJOKufzixlXryGlUZOQQoI0koic0/edit?disco=AAAAB18tyOI )

Given this bug is caused by an underlying Android inconsistency, I suggest we close it as 'WAI'.

Agreed.