New issue
Advanced search Search tips

Issue 720020 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Dec 3
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Dispatch touch input at a RenderWidgetHostViewChild causes crash

Project Member Reported by dtapu...@chromium.org, May 9 2017

Issue description

If I use chrome-remote-interface to dispatch touch event at an extension I get a crash of dispatching the gesture method.

The event I am dispatching from the cli is: Input.synthesizeScrollGesture({x: 5, y: 5, yDistance: 100, gestureSourceType: "touch"});

The stack trace below is slightly augmented to illustrate that the CreateSyntheticGestureTarget is being called on a RenderWidgetHostBase class (yet the child is a render view). The base implementation doesn't dispatch touch input. See 
https://cs.chromium.org/chromium/src/content/browser/renderer_host/input/synthetic_gesture_target_base.cc?l=85

#0 0x7fa402f41d07 base::debug::StackTrace::StackTrace()
#1 0x7fa402f6733d logging::LogMessage::~LogMessage()
#2 0x7fa40075114d content::RenderWidgetHostViewChildFrame::CreateSyntheticGestureTarget()
#3 0x7fa400934f83 content::RenderWidgetHostImpl::QueueSyntheticGesture()
#4 0x7fa40065cd34 content::protocol::InputHandler::SynthesizeRepeatingScroll()
#5 0x7fa40065c9ba content::protocol::InputHandler::SynthesizeScrollGesture()
#6 0x7fa4004fca98 content::protocol::Input::DispatcherImpl::synthesizeScrollGesture()
#7 0x7fa4004f372b content::protocol::DOM::DispatcherImpl::dispatch()
#8 0x7fa4005274ae content::protocol::UberDispatcher::dispatch()
#9 0x7fa400656ef8 content::DevToolsSession::Dispatch()
#10 0x7fa40067d92b content::RenderFrameDevToolsAgentHost::DispatchProtocolMessage()
#11 0x7fa4006521b7 content::DevToolsAgentHostClientImpl::OnMessage()
#12 0x7fa4005c673a _ZN4base8internal7InvokerINS0_9BindStateIMN7content21BackgroundSyncManagerEFviRKNS_8CallbackIFvvELNS0_8CopyModeE1ELNS0_10RepeatModeE1EEEEJNS_7WeakPtrIS4_EEiS9_EEES6_E3RunEPNS0_13BindStateBaseE
#13 0x7fa402f2d021 _ZNO4base8CallbackIFvvELNS_8internal8CopyModeE0ELNS2_10RepeatModeE0EE3RunEv
#14 0x7fa402f42623 base::debug::TaskAnnotator::RunTask()
#15 0x7fa402f739cd base::MessageLoop::RunTask()
#16 0x7fa402f73dbc base::MessageLoop::DeferOrRunPendingTask()
#17 0x7fa402f74186 base::MessageLoop::DoWork()
#18 0x7fa402f7624a base::(anonymous namespace)::WorkSourceDispatch()
#19 0x7fa3fa243e04 g_main_context_dispatch
#20 0x7fa3fa244048 <unknown>
#21 0x7fa3fa2440ec g_main_context_iteration
#22 0x7fa402f75fa6 base::MessagePumpGlib::Run()
#23 0x7fa402f73735 base::MessageLoop::RunHandler()
#24 0x7fa402fa873c base::RunLoop::Run()
#25 0x5604c567789f ChromeBrowserMainParts::MainMessageLoopRun()
#26 0x7fa4005f5542 content::BrowserMainLoop::RunMainMessageLoopParts()
#27 0x7fa4005f87a7 content::BrowserMainRunnerImpl::Run()
#28 0x7fa4005f07c8 content::BrowserMain()
#29 0x7fa400e2755f content::RunNamedProcessTypeMain()
#30 0x7fa400e282c2 content::ContentMainRunnerImpl::Run()
#31 0x7fa4034724b4 service_manager::Main()
#32 0x7fa400e26dc2 content::ContentMain()
#33 0x5604c4f49561 ChromeMain
#34 0x7fa3f7820f45 __libc_start_main
#35 0x5604c4f493cf <unknown>

 

Comment 1 by creis@chromium.org, May 9 2017

Components: Internals>Sandbox>SiteIsolation

Comment 2 by kenrb@chromium.org, May 10 2017

Thanks for filing this. I haven't tried to repro yet, but I have a couple of questions.

What does it mean that 'the child is a render view'? I don't fully understand that.

Also, what channel did you repro this on?
This is ToT. I reproduced this against the hangouts extension. 

Launch chrome with
"chrome --remote-debugging-port 9222"

Then connect chrome-remote-interface to the hangouts tab and send the message I indicated in comment #0.

See https://github.com/cyrus-and/chrome-remote-interface for more details.

What I was referring to is the fact that we don't have an RenderWidgetHostViewAura (as in https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_host_view_aura.cc?type=cs&q=CreateSyntheticGestureTarget+package:%5Echromium$&l=1075 doesn't get called which returns a subclass that provides touch support).

I'm not sure why this CreateSyntheticGestureTarget stuff exists on the view really.

Status: Assigned (was: Untriaged)

Comment 5 by sadrul@chromium.org, May 18 2017

Cc: sadrul@chromium.org
Ping, is this still a problem?

Comment 7 by kenrb@chromium.org, Dec 15 2017

Yes, I think ChromeDriver won't work with OOPIFs until this is fixed.

Comment 8 by nasko@chromium.org, Apr 11 2018

Given that ChromeDriver now works with OOPIFs, I wonder if this bug is still relevant?
What's the status of this one?
Status: Fixed (was: Assigned)

Sign in to add a comment