This crash occurs very frequently on mac platform and is likely preventing the fuzzer marty_html_twiddler from making much progress. Fixing this will allow more bugs to be found.

Marking this bug as a blocker for next Beta release.

If this is incorrect, please add ClusterFuzz-Wrong label and remove the ReleaseBlock-Beta label.

Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Predator and CL could not provide any possible suspects.

Using Code Search for the file, "render_widget_host_view_mac.mm" observing multiple changes landed regarding RWHV from @ccameron

ccameron@ -- Unable to pin point actual CL, could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks!

This is getting crash reports in chromecrash/ now. Should be a simple fix.

Stack is
  content::RenderWidgetHostViewMac::Show()
  content::WebContentsImpl::WasShown()
  content::WebContentsImpl::UpdateWebContentsVisibility(content::Visibility)
  ...
  +[NSEvent _discardEventsForTrackingArea:window:]
  -[NSView(NSInternal) _uninstallTrackingArea:]
  -[NSView(NSInternal) _uninstallTrackingAreas]
  -[NSView _setWindow:] 
  -[NSView removeFromSuperview]
  content::(anonymous namespace)::RenderWidgetHostViewNSViewBridgeLocal::~RenderWidgetHostViewNSViewBridgeLocal()
  content::RenderWidgetHostViewMac::Destroy()

It would be great if we could prevent WebContentsImpl::UpdateWebContentsVisibility from being called in this situation...

But I think we'll just need to set a bit if Destroy is being called.

We still have lots of "if (host())"s sprinkled throughout RWHVMac -- we can replace all of those with checking that bit.

Have a patch at https://chromium-review.googlesource.com/c/chromium/src/+/1025396

This will need a 67 merge as well.

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

commit 7a87e4e8fbbe98545bd248eb0b84108e7b2bb372
Author: Christopher Cameron <ccameron@chromium.org>
Date: Thu Apr 26 07:25:57 2018

mac: Fix WebContentsImpl::UpdateWebContentsVisibility calling RWHVMac

We encounter the following stack when destroying the RWHVMac
  RenderWidgetHostViewMac::Show
  WebContentsImpl::WasShown
  WebContentsImpl::UpdateWebContentsVisibility
  ...
  -[NSView removeFromSuperview]
  RenderWidgetHostViewNSViewBridgeLocal::~(dtor)
  RenderWidgetHostViewMac::Destroy

This is problematic, as WebContentsImpl::UpdateWebContentsVisibility
will make a bunch of calls on RenderWidgetHostViewMac that all assume
that we are not mid-tear-down.

To avoid this, make the call to -[NSView removeFromSuperview] be a
delayed callback. That way the call will happen after the RWHVMac has
been entirely destroyed, and UpdateWebContentsVisibility will no longer
have a RWHVMac to call back into.

Bug:  834931 
Change-Id: I88412173b005dfdc26026db6b4c12b31e6541e7c
Reviewed-on: https://chromium-review.googlesource.com/1025396
Reviewed-by: Sidney San Martín <sdy@chromium.org>
Commit-Queue: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#553941}
[modify] https://crrev.com/7a87e4e8fbbe98545bd248eb0b84108e7b2bb372/content/browser/renderer_host/render_widget_host_ns_view_bridge.mm
[modify] https://crrev.com/7a87e4e8fbbe98545bd248eb0b84108e7b2bb372/content/browser/renderer_host/render_widget_host_view_cocoa.mm

How is change listed at #7 looking in canary? Is it safe and worth to merge to M67?

This has indeed been fixed in Canary with no fallout that I can see.

Meanwhile in Beta 67, this is the #2 crasher
https://crash.corp.google.com/browse?q=product.name%3D%27Chrome_Mac%27+AND+product.version%3D%2767.0.3396.18%27+AND+expanded_custom_data.ChromeCrashProto.channel%3D%27beta%27+AND+expanded_custom_data.ChromeCrashProto.ptype%3D%27browser%27

So I think this is a good idea to merge.

Thank you  ccameron@. Pls request a merge to M67.

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

commit 0dc17b6fb1ecd7006abceb1c89105f166ca7d80e
Author: Christopher Cameron <ccameron@chromium.org>
Date: Wed May 02 19:12:45 2018

mac: Fix WebContentsImpl::UpdateWebContentsVisibility calling RWHVMac

We encounter the following stack when destroying the RWHVMac
  RenderWidgetHostViewMac::Show
  WebContentsImpl::WasShown
  WebContentsImpl::UpdateWebContentsVisibility
  ...
  -[NSView removeFromSuperview]
  RenderWidgetHostViewNSViewBridgeLocal::~(dtor)
  RenderWidgetHostViewMac::Destroy

This is problematic, as WebContentsImpl::UpdateWebContentsVisibility
will make a bunch of calls on RenderWidgetHostViewMac that all assume
that we are not mid-tear-down.

To avoid this, make the call to -[NSView removeFromSuperview] be a
delayed callback. That way the call will happen after the RWHVMac has
been entirely destroyed, and UpdateWebContentsVisibility will no longer
have a RWHVMac to call back into.

TBR=ccameron@chromium.org

(cherry picked from commit 7a87e4e8fbbe98545bd248eb0b84108e7b2bb372)

Bug:  834931 
Change-Id: I88412173b005dfdc26026db6b4c12b31e6541e7c
Reviewed-on: https://chromium-review.googlesource.com/1025396
Reviewed-by: Sidney San Martín <sdy@chromium.org>
Commit-Queue: ccameron <ccameron@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#553941}
Reviewed-on: https://chromium-review.googlesource.com/1040625
Reviewed-by: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/branch-heads/3396@{#446}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/0dc17b6fb1ecd7006abceb1c89105f166ca7d80e/content/browser/renderer_host/render_widget_host_ns_view_bridge.mm
[modify] https://crrev.com/0dc17b6fb1ecd7006abceb1c89105f166ca7d80e/content/browser/renderer_host/render_widget_host_view_cocoa.mm

Merge listed at #11 was approved via internal mail thread per comment #9. Thank you.

Removing "Merge-Approved-67" as it was already merged to M67 at #11.

Sorry -- mixed up the email and bug threads on approvals!