MacViews: Crash on trying to show "hung page" dialog |
|||||||
Issue description1. Go to chrome://hang 2. Click in page 3. Wait 30s [83418:1295:0326/143011.329656:FATAL:native_widget_mac.mm(345)] Check failed: bridge_ && bridge_->parent(). 0 libbase.dylib 0x00000001277476fe base::debug::StackTrace::StackTrace(unsigned long) + 174 1 libbase.dylib 0x00000001277477bd base::debug::StackTrace::StackTrace(unsigned long) + 29 2 libbase.dylib 0x0000000127745c6c base::debug::StackTrace::StackTrace() + 28 3 libbase.dylib 0x00000001277e170c logging::LogMessage::~LogMessage() + 460 4 libbase.dylib 0x00000001277df475 logging::LogMessage::~LogMessage() + 21 5 libviews.dylib 0x0000000144218046 views::NativeWidgetMac::StackAbove(NSView*) + 358 6 libviews.dylib 0x000000014422b7d0 views::Widget::StackAboveWidget(views::Widget*) + 64 7 libchrome_dll.dylib 0x00000001184439b5 HungRendererDialogView::ShowForWebContents(content::WebContents*, content::RenderWidgetHost*) + 629 8 libchrome_dll.dylib 0x00000001184430d8 HungRendererDialogView::Show(content::WebContents*, content::RenderWidgetHost*) + 104 9 libchrome_dll.dylib 0x00000001184aa931 TabDialogsViews::ShowHungRendererDialog(content::RenderWidgetHost*) + 33 10 libchrome_dll.dylib 0x0000000117b08385 Browser::RendererUnresponsive(content::WebContents*, content::RenderWidgetHost*) + 405 11 libcontent.dylib 0x000000012fff0a62 content::WebContentsImpl::RendererUnresponsive(content::RenderWidgetHostImpl*) + 322 12 libcontent.dylib 0x000000012fafe35a content::RenderWidgetHostImpl::RendererIsUnresponsive() + 186 13 libcontent.dylib 0x000000012fb236ff void base::internal::FunctorTraits<void (content::RenderWidgetHostImpl::*)(), void>::Invoke<base::WeakPtr<content::RenderWidgetHostImpl> const&>(void (content::RenderWidgetHostImpl::*)(), base::WeakPtr<content::RenderWidgetHostImpl> const&&&) + 127 14 libcontent.dylib 0x000000012fb2364a void base::internal::InvokeHelper<true, void>::MakeItSo<void (content::RenderWidgetHostImpl::* const&)(), base::WeakPtr<content::RenderWidgetHostImpl> const&>(void (content::RenderWidgetHostImpl::* const&&&)(), base::WeakPtr<content::RenderWidgetHostImpl> const&&&) + 90 15 libcontent.dylib 0x000000012fb235e0 void base::internal::Invoker<base::internal::BindState<void (content::RenderWidgetHostImpl::*)(), base::WeakPtr<content::RenderWidgetHostImpl> >, void ()>::RunImpl<void (content::RenderWidgetHostImpl::* const&)(), std::__1::tuple<base::WeakPtr<content::RenderWidgetHostImpl> > const&, 0ul>(void (content::RenderWidgetHostImpl::* const&&&)(), std::__1::tuple<base::WeakPtr<content::RenderWidgetHostImpl> > const&&&, std::__1::integer_sequence<unsigned long, 0ul>) + 80 16 libcontent.dylib 0x000000012fb2352c base::internal::Invoker<base::internal::BindState<void (content::RenderWidgetHostImpl::*)(), base::WeakPtr<content::RenderWidgetHostImpl> >, void ()>::Run(base::internal::BindStateBase*) + 44 17 libcontent.dylib 0x000000012cf4d42d base::RepeatingCallback<void ()>::Run() const & + 61 18 libcontent.dylib 0x000000012f8b38e7 content::TimeoutMonitor::CheckTimedOut() + 967 19 libcontent.dylib 0x000000012f8b402d void base::internal::FunctorTraits<void (content::TimeoutMonitor::*)(), void>::Invoke<content::TimeoutMonitor*>(void (content::TimeoutMonitor::*)(), content::TimeoutMonitor*&&) + 125 20 libcontent.dylib 0x000000012f8b3f74 void base::internal::InvokeHelper<false, void>::MakeItSo<void (content::TimeoutMonitor::* const&)(), content::TimeoutMonitor*>(void (content::TimeoutMonitor::* const&&&)(), content::TimeoutMonitor*&&) + 68 21 libcontent.dylib 0x000000012f8b3f03 void base::internal::Invoker<base::internal::BindState<void (content::TimeoutMonitor::*)(), base::internal::UnretainedWrapper<content::TimeoutMonitor> >, void ()>::RunImpl<void (content::TimeoutMonitor::* const&)(), std::__1::tuple<base::internal::UnretainedWrapper<content::TimeoutMonitor> > const&, 0ul>(void (content::TimeoutMonitor::* const&&&)(), std::__1::tuple<base::internal::UnretainedWrapper<content::TimeoutMonitor> > const&&&, std::__1::integer_sequence<unsigned long, 0ul>) + 99 22 libcontent.dylib 0x000000012f8b3e3c base::internal::Invoker<base::internal::BindState<void (content::TimeoutMonitor::*)(), base::internal::UnretainedWrapper<content::TimeoutMonitor> >, void ()>::Run(base::internal::BindStateBase*) + 44 23 libbase.dylib 0x00000001276e3a0d base::RepeatingCallback<void ()>::Run() const & + 61 24 libbase.dylib 0x0000000127a53586 base::Timer::RunScheduledTask() + 294 25 libbase.dylib 0x0000000127a533e9 base::BaseTimerTaskInternal::Run() + 73 26 libbase.dylib 0x0000000127a538dd void base::internal::FunctorTraits<void (base::BaseTimerTaskInternal::*)(), void>::Invoke<base::BaseTimerTaskInternal*>(void (base::BaseTimerTaskInternal::*)(), base::BaseTimerTaskInternal*&&) + 125 27 libbase.dylib 0x0000000127a53824 void base::internal::InvokeHelper<false, void>::MakeItSo<void (base::BaseTimerTaskInternal::*)(), base::BaseTimerTaskInternal*>(void (base::BaseTimerTaskInternal::*&&)(), base::BaseTimerTaskInternal*&&) + 68 28 libbase.dylib 0x0000000127a537b3 void base::internal::Invoker<base::internal::BindState<void (base::BaseTimerTaskInternal::*)(), base::internal::OwnedWrapper<base::BaseTimerTaskInternal> >, void ()>::RunImpl<void (base::BaseTimerTaskInternal::*)(), std::__1::tuple<base::internal::OwnedWrapper<base::BaseTimerTaskInternal> >, 0ul>(void (base::BaseTimerTaskInternal::*&&)(), std::__1::tuple<base::internal::OwnedWrapper<base::BaseTimerTaskInternal> >&&, std::__1::integer_sequence<unsigned long, 0ul>) + 99 29 libbase.dylib 0x0000000127a536f9 base::internal::Invoker<base::internal::BindState<void (base::BaseTimerTaskInternal::*)(), base::internal::OwnedWrapper<base::BaseTimerTaskInternal> >, void ()>::RunOnce(base::internal::BindStateBase*) + 57 30 libbase.dylib 0x00000001276e865c base::OnceCallback<void ()>::Run() && + 92 31 libbase.dylib 0x0000000127749d33 base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) + 947 32 libbase.dylib 0x000000012782907a base::internal::IncomingTaskQueue::RunTask(base::PendingTask*) + 234 33 libbase.dylib 0x0000000127835da6 base::MessageLoop::RunTask(base::PendingTask*) + 886 34 libbase.dylib 0x0000000127836379 base::MessageLoop::DeferOrRunPendingTask(base::PendingTask) + 89 35 libbase.dylib 0x00000001278369fd base::MessageLoop::DoDelayedWork(base::TimeTicks*) + 605 36 libbase.dylib 0x0000000127843c30 base::MessagePumpCFRunLoopBase::RunWork() + 160 37 libbase.dylib 0x0000000127843b7c ___ZN4base24MessagePumpCFRunLoopBase13RunWorkSourceEPv_block_invoke + 28 38 libbase.dylib 0x00000001277e6c3a base::mac::CallWithEHFrame(void () block_pointer) + 10 39 libbase.dylib 0x0000000127842a75 base::MessagePumpCFRunLoopBase::RunWorkSource(void*) + 101 40 CoreFoundation 0x00007fff89e4f7e1 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 41 CoreFoundation 0x00007fff89e2ef0c __CFRunLoopDoSources0 + 556 42 CoreFoundation 0x00007fff89e2e42f __CFRunLoopRun + 927 43 CoreFoundation 0x00007fff89e2de28 CFRunLoopRunSpecific + 296 44 HIToolbox 0x00007fff84bfd935 RunCurrentEventLoopInMode + 235 45 HIToolbox 0x00007fff84bfd76f ReceiveNextEventCommon + 432 46 HIToolbox 0x00007fff84bfd5af _BlockUntilNextEventMatchingListInModeWithFilter + 71 47 AppKit 0x00007fff8ea2bdf6 _DPSNextEvent + 1067 48 AppKit 0x00007fff8ea2b226 -[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 454 49 libchrome_dll.dylib 0x00000001123c6e5a __71-[BrowserCrApplication nextEventMatchingMask:untilDate:inMode:dequeue:]_block_invoke + 106 50 libbase.dylib 0x00000001277e6c3a base::mac::CallWithEHFrame(void () block_pointer) + 10 51 libchrome_dll.dylib 0x00000001123c6cf8 -[BrowserCrApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 248 52 AppKit 0x00007fff8ea1fd80 -[NSApplication run] + 682 53 libbase.dylib 0x000000012784524c base::MessagePumpNSApplication::DoRun(base::MessagePump::Delegate*) + 348 54 libbase.dylib 0x0000000127842115 base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*) + 101 55 libbase.dylib 0x000000012783555d base::MessageLoop::Run(bool) + 573 56 libbase.dylib 0x00000001279381de base::RunLoop::Run() + 606 57 libchrome_dll.dylib 0x00000001123d6a29 ChromeBrowserMainParts::MainMessageLoopRun(int*) + 361 58 libcontent.dylib 0x000000012eaae782 content::BrowserMainLoop::RunMainMessageLoopParts() + 450 59 libcontent.dylib 0x000000012eab7fca content::BrowserMainRunnerImpl::Run() + 378 60 libcontent.dylib 0x000000012eaa1a1e content::BrowserMain(content::MainFunctionParams const&) + 654 61 libcontent.dylib 0x000000013170fa88 content::RunNamedProcessTypeMain(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, content::MainFunctionParams const&, content::ContentMainDelegate*) + 600
,
Mar 26 2018
Commandline: /V/s/c/s/out ((0d5e36308964...))> debug/Chromium.app/Contents/MacOS/Chromium --enable-features=ViewsBrowserWindows
,
Mar 26 2018
Boris reached out over email about this earlier
On 25 January 2018 at 21:19, Boris Yusupov <boriay@yandex-team.ru> wrote:
> could you please explain comment and DCHECKS in NativeWidgetMac::StackAbove()
void NativeWidgetMac::StackAbove(gfx::NativeView native_view) {
// NativeWidgetMac currently only has machinery for stacking windows, and only
// stacks child windows above parents. That's currently all this is used for.
// DCHECK if a new use case comes along.
DCHECK(bridge_ && bridge_->parent());
DCHECK_EQ([native_view window], bridge_->parent()->GetNSWindow());
}
We catched this DCHECK(bridge_->parent()) in HungRendererDialogView::ShowForWebContents() and I wanted to make method alive (and probably upstream) with something like:
void NativeWidgetMac::StackAbove(gfx::NativeView native_view) {
NSWindow* window = GetNativeWindow();
NSInteger parent_window_number = [[native_view window] windowNumber];
[window orderWindow:NSWindowAbove relativeTo:parent_window_number];
}
Why do we need to worry about parent?
my reply: On 29 January 2018 at 22:34, Trent Apted <tapted@chromium.org> wrote:
I think when I put those DCHECKs in StackAbove I was assuming that Aura windows would maintain some kind of stacking relationship after the call was made. i.e. calling StackAbove(foo) would ensure the window was *always* stacked above foo, even if foo is raised/focused.
If that's not the case for Aura, then your implementation looks good.
But if it is the case for Aura, then orderWindowNSWindowAbove probably isn't going to do what the code expects.
(I haven't looked - but other options may be for the hung renderer view to just set a parent widget instead, Or just activate itself to go on top).
,
Mar 27 2018
I didn't check Aura behaviour you mentioned and because of this didn't make StackAbove() realisation. But it can be also fixed with just putting this StackAbove() under #if !defined(OS_MACOSX) Near https://cs.chromium.org/chromium/src/chrome/browser/ui/views/hung_renderer_view.cc?l=297 Because GetWidget()->Show(); later calls makeKeyAndOrderFront thus StackAbove() isn't necessary. But the best we can do is to make this window parented, because it has strange visual behaviour now: after mouse click to underlying browser window it has hidden for a while and then raised up again (for Windows, for MacOS remains hidden).
,
Mar 27 2018
I have a fix up that both parents the window and disables stacking: <https://chromium-review.googlesource.com/c/chromium/src/+/982035>
,
Mar 27 2018
,
Mar 29 2018
I had a look at the DesktopWindowTreeHostX11 code, since that's the windowing system I'm most familiar with out of this set - it uses XRestackWindows(), which I don't think is "sticky". The Windows version uses SetWindowPos(), which also appears to have a "sticky" mode (HWND_TOPMOST) which StackAbove() does not use. I tried understanding the Mus version but I got lost in a maze of Mojo IPCs. On the basis of this, I think that StackAbove() is intended to be transactional, not persistent - i.e., it changes the window order only until the order changes again somehow. There doesn't appear to be any test coverage of this at the moment so I'll try adding some.
,
Mar 29 2018
Okay, here's a fix that implements NativeWidgetMac::StackAbove() ala #3 and adds a unit test for widget stacking: https://chromium-review.googlesource.com/c/chromium/src/+/986552
,
Mar 29 2018
,
Mar 29 2018
** Bulk Edit ** FYI: Starting 04/13 M68 will be in canary, M68 Dev promotion will be on 04/26.
,
Apr 9 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7dbdba5d6ab5e8354cee17df383e411c915f2f4a commit 7dbdba5d6ab5e8354cee17df383e411c915f2f4a Author: Elly Fong-Jones <ellyjones@chromium.org> Date: Mon Apr 09 22:19:25 2018 views: implement NativeWidgetMac::StackAbove This change implements StackAbove in MacViews. Whether StackAbove is "sticky" or not is undocumented but it appears to be not sticky on Linux or Windows, which is fortunate since non-sticky is the only implementable behavior on Mac. Bug: 825937 Change-Id: Idaa4e90fd123b0d6c5bab60de3fb24417a488de1 Reviewed-on: https://chromium-review.googlesource.com/986552 Reviewed-by: Scott Violet <sky@chromium.org> Commit-Queue: Elly Fong-Jones <ellyjones@chromium.org> Cr-Commit-Position: refs/heads/master@{#549301} [modify] https://crrev.com/7dbdba5d6ab5e8354cee17df383e411c915f2f4a/ui/views/bubble/bubble_dialog_delegate.cc [modify] https://crrev.com/7dbdba5d6ab5e8354cee17df383e411c915f2f4a/ui/views/widget/native_widget_mac.mm
,
Apr 10 2018
Confirmed fixed in 67.0.3393.0.
,
May 4 2018
Tried checking the issue on latest canary 68.0.3419.0 using Mac 10.13.1 with the below mentioned steps. 1. Launched chrome 2. Navigated to Chrome://hang 3. Clicked on page and waited for 30 secs. We observed page unresponsive dialogue. We have even checked version 67.0.3393.0 as per comment#12 and 67.0.3390.0 (...assuming this version without fix). We have seen similar behaviour on all the three mentioned versions. Attaching the screenshots of same. @ellyjones: Could you please have a look at the screen shots and let us know if anything missed from our end. Please help us in verifying the fix. Thanks!
,
May 7 2018
#13: This crash will only repro on debug builds (or release builds with dcheck_always_on) since the crash is a failing DCHECK. It never affected canary or any release channel. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by ellyjo...@chromium.org
, Mar 26 2018Status: Assigned (was: Untriaged)