Can you provide more reproduction information?

Enable Mash by either:

- going to chrome://flags and search for #mash and enable it.
- or sudo vim /etc/chrome_dev.conf, and add a line:
   --enable-features=Mash

Open any webpage and try to scroll the contents using touch.

Thank you for providing more feedback. Adding the requester to the cc list.

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

Yup. Not only scroll but also other touch gestures like tap don't work either.
However the raw touch events are still being delivered to the renderer. So gesture event routing somewhere is faulty.

+msw re: event routing

Is this the old mash or the new mash?

The renderer does not receive events directly from ash/window-service, instead it receives the events through the browser, right? If it is correct, and if the events in the browser-mus are still routed through aura, then the gesture-recognizer in aura (e.g. in [1, 2] etc.) in the browser should kick in and generate the correct gesture events. The two issues that may affect things: (1) the touch-events are being marked as having been handled, thus not contributing to gesture-dispatch, and/or (2) the touch-acks from the rnederer are not reaching the gesture-recognizer in aura.

[1] https://cs.chromium.org/chromium/src/ui/aura/window_event_dispatcher.cc?l=631
[2] https://cs.chromium.org/chromium/src/ui/aura/window_event_dispatcher.cc?l=198

How do I tell if this is old vs new mash?

This is on ToT today.

It's new mash (we only have one mash, which is ws2).

afakhry, might you have some time to investigate where this is failing? In theory the code in ash that forwards to the browser is likely here: https://chromium.googlesource.com/chromium/src/+/master/services/ui/ws2/server_window.cc#221 . If you don't have time for this, don't worry, we will get to it soon.

sky@ I tried again today. Here's a stack trace:

[244359:244359:0816/191054.719126:FATAL:render_widget_host_input_event_router.cc(601)] Check failed: false. Touch events should not be routed to a destroyed target View.
#0 0x7f4bfc93406c base::debug::StackTrace::StackTrace()
#1 0x7f4bfc86810b logging::LogMessage::~LogMessage()
#2 0x7f4bfa6a42de content::RenderWidgetHostInputEventRouter::DispatchTouchEvent()
#3 0x7f4bfa6a65c1 content::RenderWidgetHostInputEventRouter::DispatchEventToTarget()
#4 0x7f4bfa6b596e content::RenderWidgetTargeter::FoundTarget()
#5 0x7f4bfa6b547a content::RenderWidgetTargeter::FindTargetAndDispatch()
#6 0x7f4bfa882342 content::RenderWidgetHostViewEventHandler::OnTouchEvent()
#7 0x7f4bf82b15cc ui::EventHandler::OnEvent()
#8 0x7f4bf82b054e ui::EventDispatcher::ProcessEvent()
#9 0x7f4bf82b02e3 ui::EventDispatcherDelegate::DispatchEvent()
#10 0x7f4bf82b1fd2 ui::EventProcessor::OnEventFromSource()
#11 0x7f4bf82b25ce ui::EventSource::SendEventToSinkFromRewriter()
#12 0x7f4bf7eaad3c aura::WindowTreeClient::OnWindowInputEvent()
#13 0x7f4bf7ed3c20 ui::mojom::WindowTreeClientStubDispatch::Accept()
#14 0x7f4bfcbcc856 mojo::InterfaceEndpointClient::HandleValidatedMessage()
#15 0x7f4bfcbcc186 mojo::FilterChain::Accept()
#16 0x7f4bfcbcdbe5 mojo::InterfaceEndpointClient::HandleIncomingMessage()
#17 0x7f4bfcbd416b mojo::internal::MultiplexRouter::ProcessIncomingMessage()
#18 0x7f4bfcbd3590 mojo::internal::MultiplexRouter::Accept()
#19 0x7f4bfcbcc186 mojo::FilterChain::Accept()
#20 0x7f4bfcbc7193 mojo::Connector::ReadSingleMessage()
#21 0x7f4bfcbc7be1 mojo::Connector::ReadAllAvailableMessages()
#22 0x7f4bfcbc7a89 mojo::Connector::OnHandleReadyInternal()
#23 0x7f4bfcbc82d7 mojo::SimpleWatcher::DiscardReadyState()
#24 0x7f4bfcb8db74 mojo::SimpleWatcher::OnHandleReady()
#25 0x7f4bfcb8e081 _ZN4base8internal7InvokerINS0_9BindStateIMN4mojo13SimpleWatcherEFvijRKNS3_18HandleSignalsStateEEJNS_7WeakPtrIS4_EEijS5_EEEFvvEE7RunImplIRKS9_RKNSt3__15tupleIJSB_ijS5_EEEJLm0ELm1ELm2ELm3EEEEvOT_OT0_NSI_16integer_sequenceImJXspT1_EEEE
#26 0x7f4bfc84b0e5 base::debug::TaskAnnotator::RunTask()
#27 0x7f4bfc87604a base::MessageLoop::RunTask()
#28 0x7f4bfc876543 base::MessageLoop::DoWork()
#29 0x7f4bfc954949 base::MessagePumpLibevent::Run()
#30 0x7f4bfc875af4 base::MessageLoop::Run()
#31 0x7f4bfc8a8c19 base::RunLoop::Run()
#32 0x55d7124f7bfd ChromeBrowserMainParts::MainMessageLoopRun()
#33 0x7f4bfa2d9927 content::BrowserMainLoop::RunMainMessageLoopParts()
#34 0x7f4bfa2dc626 content::BrowserMainRunnerImpl::Run()
#35 0x7f4bfa2d5ad9 content::BrowserMain()
#36 0x7f4bfadb6bad content::ContentMainRunnerImpl::Run()
#37 0x7f4bfcbfbf85 service_manager::Main()
#38 0x7f4bfadb5054 content::ContentMain()
#39 0x55d7118b5e73 ChromeMain
#40 0x7f4bed8542b1 __libc_start_main
#41 0x55d7118b5cea _start

+mukai re: gesture recognizer mentions above.

I'm seeing the check failure in #13 trying to run telemetry tests with SingleProcessMash.

export WORKAROUNDS='--use-gl=desktop --use_virtualized_gl_contexts'
./tools/perf/run_benchmark --browser=exact --browser-executable=./out/Default/chrome     --extra-browser-args="${WORKAROUNDS} --enable-features=SingleProcessMash" --show-stdout --reset-results --story-filter=youtube smoothness.oop_rasterization.top_25_smooth

It dies when trying to do the first page scroll on youtube.com.

The telemetry test is also crashing on device, but I'm not sure yet if the root cause is the same.

If I comment out the NOTREACHED in render_widget_host_input_event_router.cc the test doesn't crash, but doesn't scroll either.

Thanks for continuing to try Ahmed!

I'm a bit hesitant to spend much time on this as we are likely going to change around how WebContents interacts with the window-service. I'm hoping that work ends up fixing these issues (881574).

I will take a quick look at this to see if there is something obvious to make it work.

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

commit 772f038882be74941a21df5f0294f37306666b53
Author: Chong Zhang <chongz@chromium.org>
Date: Thu Sep 13 23:49:07 2018

Disable TopControlsSlideControllerTest.TestScrollingMaximizedPageBeforeGoingToTabletMode on mash

Consistently failing since
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Mojo%20ChromiumOS/34744

Bug:  866991 
Change-Id: Idd9ea206c37b53fd0b2d8fa516c8cb486d1eb7b6
Reviewed-on: https://chromium-review.googlesource.com/1225100
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Chong Zhang <chongz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#591214}
[modify] https://crrev.com/772f038882be74941a21df5f0294f37306666b53/testing/buildbot/filters/chromeos.mash.fyi.browser_tests.filter

This should be fixed with e46b335bf85509c6a33dadab359b94f0bc043756, at least for the single-process-mash case. Also note, there are still issues with OOPIFs, but I don't believe the page this is filed against has OOPIFs.