New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 598005 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Mar 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

OOPIF: DCHECK(attached_) after two right-click-inspects

Project Member Reported by alex...@chromium.org, Mar 25 2016

Issue description

1) Launch a debug build of Chrome with --site-per-process
2) Navigate to http://csreis.github.io/tests/cross-site-iframe-simple.html
3) Right-click anywhere on the iframe and choose Inspect.  A new devtools window should pop up.
4) Right-click anywhere on the main frame and choose Inspect.

This hits DCHECK(attached_) in RenderFrameDevToolsAgentHost::FrameHostHolder::InspectElement:

[33625:33625:0325/112858:FATAL:render_frame_devtools_agent_host.cc(216)] Check failed: attached_. 
#0 0x7f80df5477de base::debug::StackTrace::StackTrace()
#1 0x7f80df5a7f2f logging::LogMessage::~LogMessage()
#2 0x7f80d8eb3374 content::RenderFrameDevToolsAgentHost::FrameHostHolder::InspectElement()
#3 0x7f80d8eb5dd8 content::RenderFrameDevToolsAgentHost::InspectElement()
#4 0x7f80e3b3027c DevToolsWindow::InspectElement()
#5 0x7f80e0dccd28 RenderViewContextMenu::Inspect()
#6 0x7f80e0dcbcf8 RenderViewContextMenu::ExecuteCommand()
#7 0x7f80e2b1d535 RenderViewContextMenuViews::ExecuteCommand()
#8 0x7f80dd3cfb9d ui::SimpleMenuModel::ActivatedAt()
#9 0x7f80d49dbac5 views::MenuModelAdapter::ExecuteCommand()
#10 0x7f80d49df94f views::internal::MenuRunnerImpl::MenuDone()
#11 0x7f80d49df792 views::internal::MenuRunnerImpl::RunMenuAt()
#12 0x7f80d49deb36 views::MenuRunner::RunMenuAt()
#13 0x7f80e41b0d35 ToolkitDelegateViews::RunMenuAt()
#14 0x7f80e2b1ccb6 RenderViewContextMenuViews::RunMenuAt()
#15 0x7f80e2b1d987 RenderViewContextMenuViews::Show()
#16 0x7f80e2b1e6f5 ChromeWebContentsViewDelegateViews::ShowMenu()
#17 0x7f80e2b1e781 ChromeWebContentsViewDelegateViews::ShowContextMenu()
#18 0x7f80d9808c37 content::WebContentsViewAura::ShowContextMenu()
#19 0x7f80d97e28ea content::WebContentsImpl::ShowContextMenu()
#20 0x7f80d9026c71 content::RenderFrameHostImpl::OnContextMenu()
#21 0x7f80d903b669 _ZN4base20DispatchToMethodImplIPN7content19RenderFrameHostImplEMS2_FvRKNS1_17ContextMenuParamsEEJS4_EJLm0EEEEvRKT_T0_RKSt5tupleIJDpT1_EENS_13IndexSequenceIJXspT2_EEEE
#22 0x7f80d903b5c5 _ZN4base16DispatchToMethodIPN7content19RenderFrameHostImplEMS2_FvRKNS1_17ContextMenuParamsEEJS4_EEEvRKT_T0_RKSt5tupleIJDpT1_EE
#23 0x7f80d903b56f _ZN3IPC16DispatchToMethodIN7content19RenderFrameHostImplEMS2_FvRKNS1_17ContextMenuParamsEEvSt5tupleIJS3_EEEEvPT_T0_PT1_RKT2_
#24 0x7f80d903212b _ZN3IPC8MessageTI29FrameHostMsg_ContextMenu_MetaSt5tupleIJN7content17ContextMenuParamsEEEvE8DispatchINS3_19RenderFrameHostImplES8_vMS8_FvRKS4_EEEbPKNS_7MessageEPT_PT0_PT1_T2_
#25 0x7f80d9023247 content::RenderFrameHostImpl::OnMessageReceived()
#26 0x7f80d94e7e93 content::RenderProcessHostImpl::OnMessageReceived()
#27 0x7f80d75701e3 IPC::ChannelProxy::Context::OnDispatchMessage()

In release builds, nothing happens after step 4.

dgozman@, can you please take a look?
 

Comment 1 by nasko@chromium.org, Mar 25 2016

Cc: creis@chromium.org nick@chromium.org
Labels: -Pri-3 Proj-IsolateExtensions-BlockingLaunch Pri-2
More weird behavior that might be related: if you close the subframe's devtools popup after step 3, and then inspect the top frame (either via right-click or F12), the devtools pane opens up for the wrong frame (subframe rather than main frame).  Typing location.href in the console gives "https://csreis.github.io/tests/input-types.html" rather than "http://csreis.github.io/tests/cross-site-iframe-simple.html"

Just reproed this on Linux dev (51.0.2687.0).
Project Member

Comment 3 by bugdroid1@chromium.org, Mar 29 2016

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

commit 0fe3f402fe308f7b34317be38590d23bad3c84bc
Author: dgozman <dgozman@chromium.org>
Date: Tue Mar 29 01:25:00 2016

[DevTools] Use main frame when searching/creating DevToolsAgentHost.

It was possible to create DTAH for cross-process child frame and
then get it back when asking for WebContents' DTAH.
Instead, we go for main frame explicitly.

This bug only manifested with context menu on cross-process iframe, since
we have both per-WebContents and per-frame methods. Ideally, we'd use
either one or another, but we need per-frame one now, while per-WebContents
is the way to go when cross-process frames would be inspected in the same
DevTools window.

BUG= 598005 
TEST=SitePerProcessDevToolsBrowserTest.AgentHostForPageEqualsOneForMainFrame

Review URL: https://codereview.chromium.org/1835943003

Cr-Commit-Position: refs/heads/master@{#383646}

[modify] https://crrev.com/0fe3f402fe308f7b34317be38590d23bad3c84bc/content/browser/devtools/render_frame_devtools_agent_host.cc
[modify] https://crrev.com/0fe3f402fe308f7b34317be38590d23bad3c84bc/content/browser/devtools/site_per_process_devtools_browsertest.cc

Components: Platform>DevTools
Status: Fixed (was: Assigned)
Should be fixed.
Thanks for the quick fix!  I confirmed that this is working in Mac canary 51.0.2694.1.

Sign in to add a comment