Do you think you could bisect this using https://www.chromium.org/developers/bisect-builds-py ?

Tentatively sounds like a loading issue...?

Sounds very suspiciously like  issue 637640 , adding dtapuska just in case. 

If you can record a trace with all the various scheduler options on, it might help further triage.

The problem is it doesn't happen all the time, making a bisect impossible. Generally with canary I try to restart every day(ish). When I was running stable last week I left Chrome running for most of the week and didn't restart.

Loading triager here. I'm not able to reproduce on a ToT build. Any chance you could attach a trace?

I switched to stable shortly after filing this (this bug is partly to blame) and hadn't noticed the issue. A new version was pushed to stable recently, 54.0.2840.71, and after restarting into I hit at least one really slow page load. Of course I can't repro when trying again. I'll try to remember to start tracing when I load codereview pages.

I caught a trace of this today. 'Code review, ui/views/mus/BUILD.gn' is the tab that was slow, pid 13484 in the trace.

I'm removing NeedsFeedback. If you need anything more from me just ask.

Deleted: trace_c..tmp.slow_code_review.json.gz 3.1 MB

trace_c..tmp.slow_code_review.json.gz 3.1 MB Download

The trace looks *exactly* like  issue 637640 : html parser tasks scheduled 1s apart, with the main thread completely free to do work.

dtapuska, do you mind taking a look? The problem seems way to similar for it to be different (bad scheduling particularly on codereview).


sky: if this happens again could you turn on the disabled by default scheduling options? That's renderer.scheduler and renderer.scheduler.debug.

also +skyostil 

csharrison: what you do mean by 'renderer.scheduler and renderer.scheduler.debug'? I don't see those as trace options (I'm on stable, 54.0.2840.71).

You need to go into "Manually select settings" and under the "edit categories" dropdown there is a huge list of checkboxes with the various tracing categories.

Things were slow again and I recorded another trace with the two renderer categories added. Look for the tab 'json_file_value_serializer.cc'

Deleted: slow.json.gz 7.1 MB

slow.json.gz 7.1 MB Download

Adding Blink>Scheduling to please take a look at the trace.

For whatever reason I seem to be triggering this a ton today.

+Blink>Input to get a few more eyes on this. Also +mmenke who got bit by this earlier. 

Thanks for the trace. Looks like the scheduler thinks we're in the middle of a main thread scroll gesture and is throttling expensive tasks because of that. Let me see if I can reproduce.

The code for this seems fairly fragile (And maybe hard to sufficiently cover in tests?).  Don't suppose there's some way we could rearchitect the code to avoid this sort of problem?

Does anyone have steps for triggering this? I can't seem to repro on ToT after browsing around various Rietvelt issues. Also, a quick check to see if this happens without extensions (incognito) would be useful.

I'll try 54.0.2840.71 next.

#15: Agreed that our heuristics here a bit complex. We're going to try simplifying things a bit by making some parts of this intervention more rational (e.g., forced passive event listeners), which should limit the number of special cases we need to handle. However the fundamental problem is that there's no golden source of truth about what the user is trying to do, so we'll still need to infer things as best as we can.

I do not have consistent steps to repro. I've only noticed this on codereviews and I see a lot of them. Yesterday it was reproducing more readily when using 'j' and 'k' to navigate through files, but again, it isn't consistent.

If I had consistent repro steps I would try incognito, but it doesn't happen all the time. The only extensions I have are those forced on by corp policies, but also Docs, Docs Offline, Sheets and Slides.

Still no luck reproducing but I think I can see what's going on from the trace. Somehow we're getting an unbalanced count of pending and processed main thread input events, so we perpetually think that an input event is in the queue and deprioritize other stuff as a result.

Dave, can you think of any changes recently that might have caused RendererScheduler::DidHandleInputEventOnMainThread() to not always get called for input forwarded to the main thread? In particular do we do something different for blocking vs. nonblocking events[2]?

[1] https://cs.chromium.org/chromium/src/third_party/WebKit/public/platform/scheduler/renderer/renderer_scheduler.h?l=113&gs=cpp%253Ablink%253A%253Ascheduler%253A%253Aclass-RendererScheduler%253A%253ADidHandleInputEventOnMainThread(const%2Bblink%253A%253AWebInputEvent%2B%2526)%2540chromium%252F..%252F..%252Fthird_party%252FWebKit%252Fpublic%252Fplatform%252Fscheduler%252Frenderer%252Frenderer_scheduler.h%257Cdecl&gsn=DidHandleInputEventOnMainThread&ct=xref_usages

[2] https://cs.chromium.org/chromium/src/content/renderer/input/main_thread_event_queue.cc?rcl=1478435172&l=214

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

commit b12cd2ca201c68f2a127c1af0ec0588f091706bb
Author: skyostil <skyostil@chromium.org>
Date: Mon Nov 07 16:05:01 2016

scheduler: Reset pending input event count on navigation

When a navigation happens, we should reset the number of pending input
events in the user model to avoid waiting for an acknowledgement which
may never arrive.

This is a speculative mitigation for  crbug.com/652294 .

BUG= 652294 

Review-Url: https://codereview.chromium.org/2476263002
Cr-Commit-Position: refs/heads/master@{#430281}

[modify] https://crrev.com/b12cd2ca201c68f2a127c1af0ec0588f091706bb/third_party/WebKit/Source/platform/scheduler/renderer/user_model.cc
[modify] https://crrev.com/b12cd2ca201c68f2a127c1af0ec0588f091706bb/third_party/WebKit/Source/platform/scheduler/renderer/user_model_unittest.cc

Are you folks still seeing this problem? I still haven't been able to reproduce it.

After the bug hit stable and your fix landed I switched back to canary. I haven't seen the issue since then. I've been using canary for at least a week.

Alright, sounds like the workaround is...working around. Let's backport to 56 then.

[Automated comment] Commit may have occurred before M56 branch point (11/17/2016), needs manual review.

Ah, my bad. This is already in M56.