reporter@ - Thanks for filing the issue...!!

Could you please provide sample credentials to log-into the site. This will help us in triaging the issue further.

Thanks...!!

9sdream@disbox.net
1qw23er45t

login from “登录”

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

And there is a demo with Safari vs Chrome. Resource in Chrome get a very high Content Download time when scrolling.

Deleted: nimbus-record-video-2018-04-04-17-36-35.webm 6.1 MB

	nimbus-record-video-2018-04-04-17-36-35.webm 6.1 MB View Download

Deleted: nimbus-record-video-2018-04-04-17-39-02.webm 7.1 MB

	nimbus-record-video-2018-04-04-17-39-02.webm 7.1 MB View Download

Thanks for the comparison, that's helpful.

I don't think this has to do with scrolling as much as scrolling is simply the cause of the network requests. The real issue here seems that the requests are taking unreasonably long. Moving this to networking team to take a look

code.falling@: I suspect a NetLog dump will be helplful to determine the cause. Here's instructions on how to grab those: https://www.chromium.org/for-testers/providing-network-details
 

I am afraid this issue **is** about scrolling. See this issue: https://github.com/TryGhost/Ghost/issues/7934, many projects about scrolling ran into this.

And in the comparison video, I am trying to scroll fast, Content Download time of requests keep growing unless **I stop scroll**. That is to say, the Content Download time is about the time I am scrolling.

And there is a magic workground for this issue (See https://stackoverflow.com/questions/47524205/random-high-content-download-time-in-chrome/47684257#47684257)

```js
window.addEventListener("mousewheel", (e) => {
    if (e.deltaY === 1) {
        e.preventDefault()
    }
})
```

It seems related to something about scrolling or passive event.

Sorry about that - I missed the fact that the repro required scrolling during the load.

This sounds like we're prioritizing scrolling over loading content. In M65 we've made it so that rapid mouse wheels form a single gesture stream (rather than a GestureScrollBegin, GestureScrollUpdate, GestureScrollEnd triplet for each wheel event). This means that continuously using the wheel at the bottom of the page will delay loading new content indefinitely (disabling the feature using --disable-features=AsyncWheelEvents,TouchpadAndWheelScrollLatching confirms the issue goes away).

This is analogous to how touchscreen scrolling works and I've confirmed the page also wont load new content while a finger is on the touchscreen. 

+altimin@, is this an accurate assessment? I've attached a trace with scheduling flags turned on. I worry this might be a more common scenario - wheeling impatiently at the bottom of an infinite scroller. With touchscreen the user has to release their finger occasionally to start a new scroll which mitigates this somewhat. Perhaps we should use an additional signal like page movement?

Deleted: trace_xhrdelay.json.gz 6.5 MB

trace_xhrdelay.json.gz 6.5 MB Download

Thank you for your reply. So it's there any temporary workground for this issue?

Magic code above do not works in some pages. Our web page relay on loading on scrolling is very slow now.

Hi code.falling@, unfortunately there isn't a workaround I can think of. This is something we'll have to fix on our end. 

re comment #10 : by having a blocking wheel event listener that calls preventDefault() the wheel events are not handled asynchronously anymore.

Issue 823765 has been merged into this issue.

As a temporary work around we can reduce the latching timer timeout to make sure that we break the latching and give the page load a chance to finish.
bokan@ WDYT?

I spoke with altimin@ and we agreed that the heuristics in scheduling need to be updated. I'd rather do that (I don't think it's much work, just have to be a bit careful) but don't have the bandwidth at the moment. 

It's there any update for this? Almost two month passed.

No update yet.

Chao, please do some investigation here. If you look in the trace from #11, you'll see the renderer has a bunch of RendererScheduler states (they're cut off in the trace but you can find them in https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/scheduler/main_thread/main_thread_scheduler_impl.cc?type=cs&q=TouchstartExpectedSoon&g=0&l=489).

It looks to me like wheel scrolling is putting the scheduler into a state where we block expensive tasks (probably because TouchStartExpectedSoon is erroneously true?). Once that expires the page continues to load as expected. Find where the GSB/GSUs set which scheduler state that's causing this (I'd start by looking for TouchStartExpectedSoon). Once we're sure of that we can decide to either have a more moderate policy (throttle?) or just not do it for wheel at all.

re comment #21:

If we decide to exclude wheel scrolling, we can do it only for scrolling that has synthetic phase since only in this case we can end up with a long scroll sequence due to non-stop scrolling by mouse wheel.

By conversation with skyostil@ in IM. He think we should observe have_seen_main_thread_blocking_gesture to replace the has_visible_render_widget_with_touch_handler check to determine blocking the gesture events.

I am still investigating how to calc have_seen_main_thread_blocking_gesture. Now I am think maybe set have_seen_main_thread_blocking_gesture true when input_handler_proxy receive TouchStart and |event_listener_type != NO_HANDLER| or receive Mousewheel and |DispatchType = kBlocking|.

https://cs.chromium.org/chromium/src/ui/events/blink/input_handler_proxy.cc?rcl=8043d58567a5854082c43bb47d9020d2d0d1ed51&l=999

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

commit 4a2ebc8dad89ca0042d0babd619f4ea35e3ac072
Author: chaopeng <chaopeng@chromium.org>
Date: Tue Jun 19 22:09:03 2018

Set TouchStartExpectedSoon only after we seen a blocking event

This issue is causing by:

1. MainThreadScheduler set TouchStartExpectedSoon based on the gesture event
   sequence when page has touchstart event handler
2. Scroll latching makes mouse wheels to gesture events.

We change it the check from page has touchstart event handler to we actually
cc blocking event. In the issue case, page has touchstart event handler but no
wheel event handler, user scroll with wheel will not cause a cc blocking event
so it would not block the network request.

We also change TouchStartExpectedSoon to BlockingInputExpectedSoon.

Bug:  828235 
Change-Id: Iefff163ca091f2761542a527e2c4432bc1078f4c
Reviewed-on: https://chromium-review.googlesource.com/1075719
Commit-Queue: Jianpeng Chao <chaopeng@chromium.org>
Reviewed-by: Sami Kyöstilä <skyostil@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568614}
[modify] https://crrev.com/4a2ebc8dad89ca0042d0babd619f4ea35e3ac072/third_party/blink/renderer/platform/scheduler/main_thread/main_thread_scheduler_impl.cc
[modify] https://crrev.com/4a2ebc8dad89ca0042d0babd619f4ea35e3ac072/third_party/blink/renderer/platform/scheduler/main_thread/main_thread_scheduler_impl.h
[modify] https://crrev.com/4a2ebc8dad89ca0042d0babd619f4ea35e3ac072/third_party/blink/renderer/platform/scheduler/main_thread/main_thread_scheduler_impl_unittest.cc