I'm not able to reproduce.

Maybe you have two instances of Chrome running at the same time (e.g. Stable, Canary, developer build...)?

I can reproduce this in Canary and M59 Stable on my Oneplus 3 every time. 

I just checked that I closed the right Chrome instance ;) 

I closed all apps, open chrome with an incognito tab, open task switcher and swipe chrome away. The incognito notification doesn't disappear even after waiting a few seconds.

Theresa, can you have a look or route this?

+tedchoc@ owns the incognito notification

I believe this is working as intended. We have no signal that the user swiped away the app from Android recents, so we can't dismiss the notification in the scenario described.

Agreed...this is most likely a sad "WontFix" as twellington@ mentioned, we get no signal in the case where Chrome is swiped away.  That is the equivalent of a process kill and there is nothing immediately we can do about it.  We clean up the notification the next time Chrome is started though if no longer relevant.

We could try to start a service with START_STICKY whose sole purpose is to check whether Chrome is killed, but that isn't fool proof either as we can't reliably check all tasks in Android across all versions (potentially in later versions).  That is also increasing the overhead of the notification, but likely not by a hugely terrible amount.  Granted, I don't know if START_STICKY works in the event of swiping away vs being killed by the OOM killer at the system level.

This more or less applies to other OSes as well. Once we send a notification, it stays there regardless of what happens to incognito window.
Can't we show incognito notifications in the browser? Similar to notifications for permissions?

I don't understand the #8 comment.  We don't show any notifications within the browser?  We show popups or dialogs or infobars, but those aren't notifications.  Those are asking questions of our users.

The incognito notification is letting the user know they have incognito tabs open.  We could potentially introduce some UI within the browser letting them know this, but that isn't done for anything else within Android to my understanding (we do badge the menu when you're hugely out of date, but we don't have a general purpose in product notification area...on Android at least).

Sorry, I was confused.

The privacy impact is low, but still worth caring. We can assume someone uses incognito on a shared device in an at-risk family and hurriedly closes Chrome, but the remaining notification reveals the usage.

Can't we have a feature request from Android for notifications that are removed if their app is killed?

Adding to this issue, the notification log will also show a trace of opening an incognito window.

It seems that "Firefox Klar" browser is doing that.

Steps to reproduce:
1. Goto a website using Firefox Klar.
2. Notice that there are notification message and icon saying that it is open.
3. Close it via app switcher.
4. The notifications go.

But if you see the notification log, there is also a message saying that "Firefox Klar is using battery", so probably removing the notification is coming at a cost.

Marking it WontFix as it seems that Android does not let this now.

Sorry Ted I forgot to ask if you agree or a solution is found.

Is there a clean way to do it without using a lot of battery, or we should close it as sad "Won't Fix"?

Ted, offline: "The only path to fix it would be to start the incognito service as sticky and monitor for when all of our tasks are gone.  That is going to be rather expensive.  We could also use the job scheduler, but we'd be essentially polling for our tasks to be done and doing the clean up there.  I think it could be easier if we optimized for the case you left Chrome and immediately swiped it away as we could do the check just once.  But I think really fixing this requires a change from Android to get notified when a particular task of yours is destroyed."

Changing to "External Dependency", on Android.