Meant to add to my initial report: this is definitely something connected to Android. When there are only Chrome OS notifications to clear, it works fine. When there are Android notifications, clearing crashes the browser (as noted above) as well as all running Android apps. The only way to clear Android notifications without crashing is by clicking the "x" in each notification and not using the clear-all icon.

I reported this problem before; it went away for a few stable releases and now it's back. I updated to Version 59.0.3071.134 (Official Build) (64-bit) and, once again, clicking the "clear notifications" hamburger in the bottom bar results in a black screen with the entire OS crashing.

What other information do you need to debug this because there's something happening behind the scenes where you fix it then add the problem back and, obviously, I'd like for the problem not be accidentally re-added again once you've fixed it. Thanks.

This started happening to me a few days ago when my Chromebook Plus updated to 59. No dev mode, beta channel or anything.

I'm going to pay attention to Chrome vs Android notifications after reading this thread. I know there's a few times where it *hasn't* done it, but I haven't been able to narrow down what was different about those occasions. 

Google Chrome	59.0.3071.134 (Official Build) (32-bit)

Revision	0

Platform	9460.73.0 (Official Build) stable-channel kevin

Firmware Version	Google_Kevin.8785.178.0

ARC	4127355

I updated to Version 60.0.3112.80 (Official Build) beta (64-bit) in the hopes that this problem would go away but no such luck. Still present in the beta.

I think it has to be related to Android. I'm using an Acer R11 with Play Store and notice that when I clear notifications, not only does the browser crash as noted, but the Android subsystem also completely crashes and restarts.

Google Chrome	60.0.3112.80 (Official Build) beta (64-bit)
Revision	0
Platform	9592.71.0 (Official Build) beta-channel cyan
Firmware Version	Google_Cyan.7287.57.125
ARC	4202028

Still having this issue. It consistently happens when Android and ChromeOS notifications are present together, and when just Android notifications are present. However, it still happens occasionally when ChromeOS notifications only are present. It doesn't seem to matter how many are in the tray in any scenario. 

Do you have a crash ID? You can see your crash ID in chrome://crashes if crash reporting is enabled. Please copy and paste the crash ID here. I should be a great help to fix the crash. Thanks.

I just triggered the crash again and this is the ID that was listed: 616ccb5ca423cc77. I hope that's what you need. 

It just did it again. No clue why as usual as I've been clearing notifications without a problem for a few weeks. I reported the crash right after Chrome restarted and the crash ID is: 445eac0ca28c3432

I have this bug also. 

Version 61.0.3163.80 (Official Build) beta (64-bit)

Asus C202S 

It crashed again after clearing notifications. Crash ID: be1e7f58f0a43c0a

Another crash. chrome://crashes doesn't show the recent crash for some reason. 

Platform
9765.53.0 (Official Build) beta-channel terra

Firmware
Google_Terra.7287.154.80

ARC Version
4312059

Another crash. I'm going to keep providing these updates until someone in this thread tells me to stop. 

This time, it shows up in chrome://crashes 

Crash Report ID 35642c4ff22f1cdb 

It happens on stable as well.

Did it again on most recent beta. Crash ID 2d2fff9e46b77bf4

Another crash. Crash ID 4441eab85832e42f

I'm not sure if ChromeOS is rolling back to last-known-good Verified Boot or whatever. 

After the crash, my device is on Version 61.0.3163.90 (Official Build) beta (64-bit), ARC Version 4332052

Crashed again. chrome://crashes doesn't show anything for this crash. 

I was expecting the crash, given the amount of notifications I had to clear, and sure enough, it happened. 

I cleared 11 notifications using the "clear all" button, which resulted in the crash described in this thread. 

For reference, here is what was active at the time of pressing the 'clear all' button, in case it's somehow app-specific: 
1x Hangar (persistent) 
4x YouTube 
1x Facebook Messenger 
1x Google Photos 
2x Play Newsstand 
2x GroupMe 
1x Play Store 

I found the cause. It's very tricky.

In the OnBoundsAnimatorDone, the views in deleted_when_done_ are removed. It's intentional. But some of them may have started animation just before the deletion. The animation is initiated in AnimateNotification (actually in AnimateChild). Result of that, an animator try animating a deleted view. This is a cause of the crash.

Let me fix this.

Thanks for all your crash reports and info~!

I've also been looking at this. I've found at least two other ways to cause this crash - so I think it'll take a few patches to fully fix this part of the code up.

 Issue 759884  has been merged into this issue.

Issue 750458 has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0a44241e4fd920ba8cf6aff8ab94dfd47fe1bae8

commit 0a44241e4fd920ba8cf6aff8ab94dfd47fe1bae8
Author: Eliot Courtney <edcourtney@google.com>
Date: Tue Oct 10 05:13:17 2017

Check |clearing_all_views_| before telling observers that all views have been cleared.

We currently assume that OnBoundsAnimatorDone will only be called once
all the animations in a clear all animation have been finished. But, if
all animations finished while a AnimateClearingOneNotification task is
still pending, we will think all the animations have finished and set
|clearing_all_started_| to false. When DoUpdateIfPossible is called, it
will see that |clearing_all_views_| is non-empty, and schedule
AnimateClearingOneNotification again. Now, we have two chains of
AnimateClearingOneNotification executing, so one of them will end up
calling pop_front() on an empty |clearing_all_views_|. This causes a
crash.

Bug:  692527 
Change-Id: Id2c51969e3afe8260a1b1ffb89c4cee3a9e9fce8
Reviewed-on: https://chromium-review.googlesource.com/686314
Reviewed-by: Yoshiki Iguchi <yoshiki@chromium.org>
Reviewed-by: Mitsuru Oshima <oshima@chromium.org>
Reviewed-by: Naoki Fukino <fukino@chromium.org>
Commit-Queue: Eliot Courtney <edcourtney@chromium.org>
Cr-Commit-Position: refs/heads/master@{#507594}
[modify] https://crrev.com/0a44241e4fd920ba8cf6aff8ab94dfd47fe1bae8/ash/message_center/message_list_view.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f9e0b4d8768513f5e03369958e90a6a46c0eb6ff

commit f9e0b4d8768513f5e03369958e90a6a46c0eb6ff
Author: yoshiki iguchi <yoshiki@chromium.org>
Date: Thu Oct 12 10:18:43 2017

Not remove views in OnBoundsAnimatorDone after clearing all

This patch changes the deletion timing of views on clearing all notification.

Previously they are removed in OnBoundsAnimatorDone().　This patch makes it not removing views, because it is the cause of the crash (see crbug.com/762803). Even with this change, the views are moved in the RemoveNotification method eventually.

This patch also skips setting reposition target during clearing all.

Bug:  692527 
Change-Id: Ibf55195e109d6fbe96d01717ddd774a77de5e2b4
Reviewed-on: https://chromium-review.googlesource.com/699979
Commit-Queue: Yoshiki Iguchi <yoshiki@chromium.org>
Reviewed-by: Yuichiro Hanada <yhanada@chromium.org>
Cr-Commit-Position: refs/heads/master@{#508302}
[modify] https://crrev.com/f9e0b4d8768513f5e03369958e90a6a46c0eb6ff/ash/message_center/message_center_view.cc
[modify] https://crrev.com/f9e0b4d8768513f5e03369958e90a6a46c0eb6ff/ash/message_center/message_list_view.cc
[modify] https://crrev.com/f9e0b4d8768513f5e03369958e90a6a46c0eb6ff/ash/message_center/message_list_view_unittest.cc

Checking in to let you know that this bug still exists. 

I've been using the obvious workaround, which is to clear notifications individually. 

I experienced the crash again today, in the usual, reproducible fashion. 

Version 62.0.3202.74 (Official Build) beta (64-bit) 
Crash Report ID c8ed1cf60e2b8b88 

Can we get this merged to M-62? It will not make the first stable promotion probably, but it can be teed up for a refresh.

Did this make the M-63 branch point? If not, we need to merge there too

Approved for 62 and 63 (if applicable).

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d44aa8de5b87baa2e2ee7983cf6affdccc732730

commit d44aa8de5b87baa2e2ee7983cf6affdccc732730
Author: yoshiki iguchi <yoshiki@chromium.org>
Date: Tue Nov 07 18:44:58 2017

Check |clearing_all_views_| before telling observers that all views have been cleared.

We currently assume that OnBoundsAnimatorDone will only be called once
all the animations in a clear all animation have been finished. But, if
all animations finished while a AnimateClearingOneNotification task is
still pending, we will think all the animations have finished and set
|clearing_all_started_| to false. When DoUpdateIfPossible is called, it
will see that |clearing_all_views_| is non-empty, and schedule
AnimateClearingOneNotification again. Now, we have two chains of
AnimateClearingOneNotification executing, so one of them will end up
calling pop_front() on an empty |clearing_all_views_|. This causes a
crash.

(cherry picked from commit 0a44241e4fd920ba8cf6aff8ab94dfd47fe1bae8)

Bug:  692527 
Change-Id: Id2c51969e3afe8260a1b1ffb89c4cee3a9e9fce8
Reviewed-on: https://chromium-review.googlesource.com/686314
Reviewed-by: Yoshiki Iguchi <yoshiki@chromium.org>
Reviewed-by: Mitsuru Oshima <oshima@chromium.org>
Reviewed-by: Naoki Fukino <fukino@chromium.org>
Commit-Queue: Eliot Courtney <edcourtney@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#507594}
Reviewed-on: https://chromium-review.googlesource.com/757041
Cr-Commit-Position: refs/branch-heads/3202@{#778}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/d44aa8de5b87baa2e2ee7983cf6affdccc732730/ui/message_center/views/message_list_view.cc

Merged them to M62.

And they are before the M63 branchcut, so the M63 branch contains them.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4542c250500a41c37e0c9f38e81a23d19dfc9dc9

commit 4542c250500a41c37e0c9f38e81a23d19dfc9dc9
Author: yoshiki iguchi <yoshiki@chromium.org>
Date: Tue Nov 07 18:57:51 2017

Not remove views in OnBoundsAnimatorDone after clearing all

This patch changes the deletion timing of views on clearing all notification.

Previously they are removed in OnBoundsAnimatorDone().　This patch makes it not removing views, because it is the cause of the crash (see crbug.com/762803). Even with this change, the views are moved in the RemoveNotification method eventually.

This patch also skips setting reposition target during clearing all.

(cherry picked from commit f9e0b4d8768513f5e03369958e90a6a46c0eb6ff)

Bug:  692527 
Change-Id: Ibf55195e109d6fbe96d01717ddd774a77de5e2b4
Reviewed-on: https://chromium-review.googlesource.com/699979
Commit-Queue: Yoshiki Iguchi <yoshiki@chromium.org>
Reviewed-by: Yuichiro Hanada <yhanada@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#508302}
Reviewed-on: https://chromium-review.googlesource.com/757497
Reviewed-by: Yoshiki Iguchi <yoshiki@chromium.org>
Cr-Commit-Position: refs/branch-heads/3202@{#779}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/4542c250500a41c37e0c9f38e81a23d19dfc9dc9/ui/message_center/views/message_center_view.cc
[modify] https://crrev.com/4542c250500a41c37e0c9f38e81a23d19dfc9dc9/ui/message_center/views/message_list_view.cc
[modify] https://crrev.com/4542c250500a41c37e0c9f38e81a23d19dfc9dc9/ui/message_center/views/message_list_view_unittest.cc

Issue 754617 has been merged into this issue.