cc-ing kenrb@ who worked on context menus for OOPIFs.

kenrb@: Should we just remove this DCHECK? WDYT?

Sorry for taking a long time replying. That check has been around a long time, so I don't really know if it is reasonable to remove it. It isn't obvious to me why it would be firing, so at least that would have to be clarified.

I think here is the/one reason behind firing the DCHECK:

content::RenderWidgetHostView* view =
      source_web_contents_->GetRenderWidgetHostView();
if (view)
  view->SetShowingContextMenu(false);

In the steps above the menu is alive while the page navigates. The new
RWHV does not know it had a context menu. Maybe the state for showing context menu should be stored in WebContents instread?

https://cs.chromium.org/chromium/src/components/renderer_context_menu/render_view_context_menu_base.cc?rcl=d6dbbe9a3f1a62bc6ec0414bd4bbd5d4c2d9f833&l=349

Is there any active investigation on this bug?
Otherwise please land a change to disable the DCHECK, as it affects using the Chrome Debug builds (I was testing the target_os="chromeos" build running on Linux).

The complete stack trace:
[FATAL:render_widget_host_view_base.cc(170)] Check failed: showing_context_menu_ != showing (0 vs. 0)
#0 0x7f885c3181bb base::debug::StackTrace::StackTrace()
#1 0x7f885c316efc base::debug::StackTrace::StackTrace()
#2 0x7f885c3830d7 logging::LogMessage::~LogMessage()
#3 0x7f885606e31b content::RenderWidgetHostViewBase::SetShowingContextMenu()
#4 0x55a977e5e2cb RenderViewContextMenuBase::MenuClosed()
#5 0x7f88591ceec3 ui::SimpleMenuModel::OnMenuClosed()
#6 0x7f88591d22d7 _ZN4base8internal13FunctorTraitsIMN2ui15SimpleMenuModelEFvvEvE6InvokeIRKNS_7WeakPtrIS3_EEJEEEvS5_OT_DpOT0_
#7 0x7f88591d21ca _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIRKMN2ui15SimpleMenuModelEFvvERKNS_7WeakPtrIS5_EEJEEEvOT_OT0_DpOT1_
#8 0x7f88591d2152 _ZN4base8internal7InvokerINS0_9BindStateIMN2ui15SimpleMenuModelEFvvEJNS_7WeakPtrIS4_EEEEEFvvEE7RunImplIRKS6_RKSt5tupleIJS8_EEJLm0EEEEvOT_OT0_NS_13IndexSequenceIJX
spT1_EEEE
#9 0x7f88591d206c _ZN4base8internal7InvokerINS0_9BindStateIMN2ui15SimpleMenuModelEFvvEJNS_7WeakPtrIS4_EEEEEFvvEE3RunEPNS0_13BindStateBaseE
#10 0x7f885c2d75fe _ZNO4base8CallbackIFvvELNS_8internal8CopyModeE0ELNS2_10RepeatModeE0EE3RunEv
#11 0x7f885c31d6b1 base::debug::TaskAnnotator::RunTask()
#12 0x7f885c3a7c9e base::MessageLoop::RunTask()
#13 0x7f885c3a7f00 base::MessageLoop::DeferOrRunPendingTask()
#14 0x7f885c3a8134 base::MessageLoop::DoWork()
#15 0x7f885c3b9376 base::MessagePumpGlib::Run()
#16 0x7f885c3a787d base::MessageLoop::RunHandler()
#17 0x7f885c445dd4 base::RunLoop::Run()
#18 0x55a97439b566 ChromeBrowserMainParts::MainMessageLoopRun()
#19 0x7f885571d34b content::BrowserMainLoop::RunMainMessageLoopParts()
#20 0x7f8855729325 content::BrowserMainRunnerImpl::Run()
#21 0x7f8855716df8 content::BrowserMain()
#22 0x7f8856f08c26 content::RunNamedProcessTypeMain()
#23 0x7f8856f0ad0f content::ContentMainRunnerImpl::Run()
#24 0x7f8856f078ba content::ContentServiceManagerMainDelegate::RunEmbedderProcess()
#25 0x7f885ca8fef7 service_manager::Main()
#26 0x7f8856f0874b content::ContentMain()
#27 0x55a972387d5e ChromeMain
#28 0x55a972387c72 main

I have been looking at this bug for a while. I have also put up a fix to move the logic from RWHV to WebContents which will stop the DCHECKs (at least the ones reproduced using the explanation in the bug description).

But we should also try to figure out if we are supposed to continue showing the context menu when the page navigates. Maybe we should just hide it as the RWHV is destroyed?

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

commit f6750aae23ef4c4fd8e500f092bff269ca277abc
Author: ekaramad <ekaramad@chromium.org>
Date: Tue Jun 06 18:29:42 2017

Move ContextMenu show/hide state tracking to WebContents

Currently, RenderWidgetHostView of the page tracks the visibility state of context
menus. However, the RWHV might go away during navigations (cross origin). On the
other hand, a context menu might outlive the RWHV and stay visible during the page
navigation which leads to a mismatch between the stored visibility state in the
new RWHV and the actual visibility of the context menu.

This CL will move this state tracking logic to WebContents which stays the same
during page navigations.

BUG= 708182 

Review-Url: https://codereview.chromium.org/2890143003
Cr-Commit-Position: refs/heads/master@{#477346}

[modify] https://crrev.com/f6750aae23ef4c4fd8e500f092bff269ca277abc/chrome/browser/ui/cocoa/tab_contents/chrome_web_contents_view_delegate_mac.mm
[modify] https://crrev.com/f6750aae23ef4c4fd8e500f092bff269ca277abc/components/renderer_context_menu/render_view_context_menu_base.cc
[modify] https://crrev.com/f6750aae23ef4c4fd8e500f092bff269ca277abc/content/browser/renderer_host/render_widget_host_delegate.cc
[modify] https://crrev.com/f6750aae23ef4c4fd8e500f092bff269ca277abc/content/browser/renderer_host/render_widget_host_delegate.h
[modify] https://crrev.com/f6750aae23ef4c4fd8e500f092bff269ca277abc/content/browser/renderer_host/render_widget_host_view_base.cc
[modify] https://crrev.com/f6750aae23ef4c4fd8e500f092bff269ca277abc/content/browser/renderer_host/render_widget_host_view_base.h
[modify] https://crrev.com/f6750aae23ef4c4fd8e500f092bff269ca277abc/content/browser/renderer_host/render_widget_host_view_event_handler.cc
[modify] https://crrev.com/f6750aae23ef4c4fd8e500f092bff269ca277abc/content/browser/renderer_host/render_widget_host_view_mac.h
[modify] https://crrev.com/f6750aae23ef4c4fd8e500f092bff269ca277abc/content/browser/renderer_host/render_widget_host_view_mac.mm
[modify] https://crrev.com/f6750aae23ef4c4fd8e500f092bff269ca277abc/content/browser/web_contents/web_contents_impl.cc
[modify] https://crrev.com/f6750aae23ef4c4fd8e500f092bff269ca277abc/content/browser/web_contents/web_contents_impl.h
[modify] https://crrev.com/f6750aae23ef4c4fd8e500f092bff269ca277abc/content/public/browser/render_widget_host_view.h
[modify] https://crrev.com/f6750aae23ef4c4fd8e500f092bff269ca277abc/content/public/browser/web_contents.h

Marking this bug as fixed per comment #6.