Potential jank caused by InterceptNavigationDelegate::ShouldIgnoreNavigation() |
|||||
Issue descriptionWe collected slow reports from users facing janks and found that the function mentioned above is taking too much time on the main thread, potentially causing janks. The issue can be found in reports: // InterceptNavigationDelegate is slow: a796285ac073ae51 ,9370.422 ms 4837f212797a82be ,253.846 ms 72e6f6ea59943bcd ,161.56 ms bb6ffb943bd78654 ,138.256 ms Go to crash/ReportID to view the traces. The stack trace that was hit the most: ioctl / android::IPCThreadState::talkWithDriver() / art::Lock() <Skipped java frames> navigation_interception::InterceptNavigationDelegate::ShouldIgnoreNavigation(navigation_interception::NavigationParams const&) _ZN12_GLOBAL__N_133ChromeInterceptNavigationDelegate22ShouldIgnoreNavigationERKN23navigation_interception16NavigationParamsE$c705d4d66ab1dff73fd1f2301950b471 navigation_interception::InterceptNavigationThrottle::CheckIfShouldIgnoreNavigation(bool) navigation_interception::InterceptNavigationThrottle::WillStartRequest() content::NavigationHandleImpl::CheckWillStartRequest() content::NavigationHandleImpl::WillStartRequest(base::RepeatingCallback<void (content::NavigationThrottle::ThrottleCheckResult)> const&) content::NavigationRequest::BeginNavigation() content::RenderFrameHostImpl::ProcessBeforeUnloadACKFromFrame(bool, bool, content::RenderFrameHostImpl*, bool, base::TimeTicks const&, base::TimeTicks const&) content::RenderFrameHostImpl::ProcessBeforeUnloadACK(bool, bool, base::TimeTicks const&, base::TimeTicks const&) content::RenderFrameHostImpl::OnBeforeUnloadACK(bool, base::TimeTicks const&, base::TimeTicks const&) content::RenderFrameHostImpl::OnMessageReceived(IPC::Message const&) IPC::ChannelProxy::Context::OnDispatchMessage(IPC::Message const&) base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) base::MessageLoopImpl::DoWork() base::MessagePumpForUI::OnNonDelayedLooperCallback() base::(anonymous namespace)::NonDelayedLooperCallback(int, int, void*)
,
Nov 16
There are lot of more of these cases on latest canary versions with slightly different stack traces: <skipping java frames> navigation_interception::InterceptNavigationDelegate::ShouldIgnoreNavigation(navigation_interception::NavigationParams const&) _ZN12_GLOBAL__N_133ChromeInterceptNavigationDelegate22ShouldIgnoreNavigationERKN23navigation_interception16NavigationParamsE$5b7dbee4957558918a5d4749873c3869 navigation_interception::InterceptNavigationThrottle::RunCheckAsync(navigation_interception::NavigationParams const&) base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) base::MessageLoop::RunTask(base::PendingTask*) base::MessageLoop::DoWork() base::MessagePumpForUI::OnNonDelayedLooperCallback() base::(anonymous namespace)::NonDelayedLooperCallback(int, int, void*)
,
Nov 16
Note: we observe more of these cases because we started uploading more reports on navigation.
,
Nov 16
Samples of where "InterceptNavigationThrottle::RunCheckAsync()" is slow: c150d6bd38ba4a62 124.773 ms 5cdb1d2329fad770 125.132 ms 9c3a88d69a64e0c5 139.112 ms caa1708d9eb67a4a 162.449 ms 5aa637503e22a667 235.653 ms
,
Nov 16
+Charlie I found this doc related to this issue https://bit.ly/2JgkZyc. can you help me understand what might be going on here?
,
Nov 16
,
Nov 19
This is a call into the system to determine whether a navigation should be ignored by Chrome's navigation system and handled elsewhere (e.g. by an intent). Previously, this was done synchronously during navigation start, which delayed sending out the navigation request. I have an ongoing experiment which performs this check asynchronously, but still on the main thread (so jank can still occur). A follow-up can certainly look into putting this work on a background thread. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by ssid@chromium.org
, Nov 16