Segfaults in tab dragging test on single-process mash |
|||
Issue descriptionEnabling the following three disabled tests results in segfaults on CrOS in single_process_mash_interactive_ui_tests: DetachToBrowserTabDragControllerTest.DragAllToSeparateWindow DetachToBrowserTabDragControllerTest.DragAllToSeparateWindowAndCancel DetachToBrowserTabDragControllerTest.DragSingleTabToSeparateWindow Here's a representative callstack: #0 0x555ce617f0ff base::debug::StackTrace::StackTrace() #1 0x555ce59d72c5 content::(anonymous namespace)::DumpStackTraceSignalHandler() #2 0x7f603114fcb0 <unknown> #3 0x555cea1eeb85 aura::test::(anonymous namespace)::UIControlsOzone::SendEventToSink() #4 0x555cea1ef290 aura::test::(anonymous namespace)::UIControlsOzone::PostMouseEventTask() #5 0x555cea1ef314 _ZN4base8internal7InvokerINS0_9BindStateIMN4aura4test12_GLOBAL__N_115UIControlsOzoneEFvN2ui9EventTypeERKN3gfx5PointEiiNS_12OnceCallbackIFvvEEEEJNS0_17UnretainedWrapperIS6_EES8_SA_iiSF_EEESE_E7RunOnceEPNS0_13BindStateBaseE #6 0x555ce61a33a1 base::debug::TaskAnnotator::RunTask() #7 0x555ce60e772f base::MessageLoopImpl::RunTask() #8 0x555ce60e7cf3 base::MessageLoopImpl::DoWork() #9 0x555ce619df00 base::MessagePumpLibevent::Run() #10 0x555ce60e72d8 base::MessageLoopImpl::Run() #11 0x555ce610e3d9 base::RunLoop::Run() #12 0x555ce59e4643 content::MessageLoopRunner::Run() #13 0x555ce216cdfa ui_test_utils::SendMouseEventsSync() #14 0x555ce21d42a8 DetachToBrowserTabDragControllerTest_DragAllToSeparateWindow_Test::RunTestOnMainThread() #15 0x555ce59d6909 content::BrowserTestBase::ProxyRunTestOnMainThreadLoop() #16 0x555ce54b87d7 ChromeBrowserMainParts::PreMainMessageLoopRunImpl() #17 0x555ce54b758b ChromeBrowserMainParts::PreMainMessageLoopRun() #18 0x555ce413b080 chromeos::ChromeBrowserMainPartsChromeos::PreMainMessageLoopRun() #19 0x555ce3413ff5 content::BrowserMainLoop::PreMainMessageLoopRun() #20 0x555ce38db3b5 content::StartupTaskRunner::RunAllTasksNow() #21 0x555ce3412cf5 content::BrowserMainLoop::CreateStartupTasks() #22 0x555ce3416279 content::BrowserMainRunnerImpl::Initialize() #23 0x555ce3410c1b content::BrowserMain() #24 0x555ce52956a3 content::ContentMainRunnerImpl::Run() #25 0x555ce76c7346 service_manager::Main() #26 0x555ce52939f4 content::ContentMain() #27 0x555ce59d64fc content::BrowserTestBase::SetUp() #28 0x555ce54a8481 InProcessBrowserTest::SetUp() #29 0x555ce236c830 testing::Test::Run() #30 0x555ce236d5cf testing::TestInfo::Run() #31 0x555ce236daf7 testing::TestCase::Run() #32 0x555ce2379d37 testing::internal::UnitTestImpl::RunAllTests() #33 0x555ce23798ad testing::UnitTest::Run() #34 0x555ce60ba5b1 base::TestSuite::Run() #35 0x555ce216d3f3 InteractiveUITestSuiteRunner::RunTestSuite() #36 0x555ce59e093a content::LaunchTests() #37 0x555ce54a2203 LaunchChromeTests() #38 0x555ce216d39d main #39 0x7f603113af45 __libc_start_main #40 0x555ce203b7ea _start Scott, can you triage?
,
Dec 3
,
Dec 3
This is because the default browser window gets destructed during the test instance -- but UIControlsOzone keeps the reference to that window. The UIControlsOzone is tied with a WindowTreeHost and assumes that is not deleted. We should make a logic for updating it, or we should have something like UIControlsMus which can deal with individual WindowTreeHost deletion. I'll go with the latter.
,
Dec 5
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b30b08b3f1692010376f8beeb2d1b4416eb0b00e commit b30b08b3f1692010376f8beeb2d1b4416eb0b00e Author: Jun Mukai <mukai@chromium.org> Date: Wed Dec 05 01:14:11 2018 allow callback for events which are processed in a different host When a capture happens in a different window tree host, injected events can be processed by a different event dispatcher, but InjectedEventHandler should call the callback when processing of such events finishes. This CL: - removes |dispatcher|'s check in InjectedEventHandler - allows InjectedEventHandler to check events globally instead of checking on a specific window tree host. Bug: 910791 Test: the new test case covers Change-Id: I8f039457e74d826b06a4b7d16e18aaa89d022c8e Reviewed-on: https://chromium-review.googlesource.com/c/1361866 Commit-Queue: Jun Mukai <mukai@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Cr-Commit-Position: refs/heads/master@{#613795} [modify] https://crrev.com/b30b08b3f1692010376f8beeb2d1b4416eb0b00e/ash/ws/window_service_delegate_impl.cc [modify] https://crrev.com/b30b08b3f1692010376f8beeb2d1b4416eb0b00e/ash/ws/window_service_delegate_impl.h [modify] https://crrev.com/b30b08b3f1692010376f8beeb2d1b4416eb0b00e/ash/ws/window_service_delegate_impl_unittest.cc [modify] https://crrev.com/b30b08b3f1692010376f8beeb2d1b4416eb0b00e/services/ws/injected_event_handler.cc [modify] https://crrev.com/b30b08b3f1692010376f8beeb2d1b4416eb0b00e/services/ws/test_window_service_delegate.cc [modify] https://crrev.com/b30b08b3f1692010376f8beeb2d1b4416eb0b00e/services/ws/test_window_service_delegate.h [modify] https://crrev.com/b30b08b3f1692010376f8beeb2d1b4416eb0b00e/services/ws/test_ws/test_window_service.cc [modify] https://crrev.com/b30b08b3f1692010376f8beeb2d1b4416eb0b00e/services/ws/test_ws/test_window_service.h [modify] https://crrev.com/b30b08b3f1692010376f8beeb2d1b4416eb0b00e/services/ws/window_service_delegate.h
,
Dec 6
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8dbf8cb7525f089bfb08506c2ac7e40dccf49ac0 commit 8dbf8cb7525f089bfb08506c2ac7e40dccf49ac0 Author: Jun Mukai <mukai@chromium.org> Date: Thu Dec 06 19:06:21 2018 Remove dependency on WindowTreeHost from UIControlsOzone in Mus The WindowTreeHost is tied with a toplevel window in Mus; removal of WindowTreeHost can happen very easily. Note that this CL only allows two of the three reported failures DetachToBrowserTabDragControllerTest.DragAllToSeparateWindow DetachToBrowserTabDragControllerTest.DragAllToSeparateWindowAndCancel DetachToBrowserTabDragControllerTest.DragSingleTabToSeparateWindow is confirmed not crashing, but failing anyways. Bug: 910791 Test: single_process_mash_interactive_ui_tests Change-Id: If2edb91951e01df13c510a1cd71d1d0ed6d45244 Reviewed-on: https://chromium-review.googlesource.com/c/1363854 Commit-Queue: Jun Mukai <mukai@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Cr-Commit-Position: refs/heads/master@{#614435} [modify] https://crrev.com/8dbf8cb7525f089bfb08506c2ac7e40dccf49ac0/chrome/browser/ui/views/tabs/tab_drag_controller_interactive_uitest.cc [modify] https://crrev.com/8dbf8cb7525f089bfb08506c2ac7e40dccf49ac0/ui/aura/test/ui_controls_factory_ozone.cc
,
Dec 6
,
Jan 7
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a4609f35197f04b72fa16d77503e5497a4e572b5 commit a4609f35197f04b72fa16d77503e5497a4e572b5 Author: Peter Kasting <pkasting@chromium.org> Date: Mon Jan 07 19:21:19 2019 Re-enable disabled test. DragSingleTabToSeparateWindow was verifying that the window bounds didn't change after dragging a tab in. However, since the source window was closing, the destination window seemed to be getting resized/repositioned on CrOS. Instead, verify this in DragDirectlyToSecondWindow, which doesn't have a closing source window. Bug: 910791 Change-Id: I8e5b847d4a9a87a17a323245bdf3604d07331086 Reviewed-on: https://chromium-review.googlesource.com/c/1394926 Reviewed-by: Scott Violet <sky@chromium.org> Commit-Queue: Peter Kasting <pkasting@chromium.org> Cr-Commit-Position: refs/heads/master@{#620418} [modify] https://crrev.com/a4609f35197f04b72fa16d77503e5497a4e572b5/chrome/browser/ui/views/tabs/tab_drag_controller_interactive_uitest.cc |
|||
►
Sign in to add a comment |
|||
Comment 1 by sky@chromium.org
, Dec 3Owner: mukai@chromium.org