I suspect this is related to the ResourceLoadScheduler experiment rolling out in 66.

+kinuko, toyoshim -- could you take a look?

Thanks for the report. We're rolling back the Finch change, so it should start working again at least for now.

I suspect we might need to implement something for 'hanging gets' to work around these issues (cf. https://bugs.chromium.org/p/chromium/issues/detail?id=754918#c19).

Re #2: if we want to ship this, it seems that the easiest way is to make sure that existing exceptions (like websockets) apply to load request throttling as well and add webchannel to this list of whitelisted APIs. I'll upload a couple of patches given that is closely related to my work on worker throttling anyway.

Is this a regression now? This keeps happening to all my Slack tabs, Intercom tabs, etc. Their websockets stop working the moment document.onfreeze happens.

This happened the moment PageLifecycle switched from experimental to stable. ( https://groups.google.com/a/chromium.org/forum/?hl=en#!searchin/chromium-reviews/PageLifecycle%7Csort:date/chromium-reviews/_gbOHwIIm_A/DeKjc7RsAAAJ )

I have also no way to prevent tabs from freezing, and preventing them from discarding doesn't help.

How to reproduce ( Slack in this example, but also happens with Intercom - maybe Google Voice as well? )

1. Open a Slack chat, with devtools open, and then monitor the websocket frames ( if not visible then make sure the horizontal frame slider doesn't take 100% of the page - https://stackoverflow.com/questions/44533111/chrome-59-websocket-frames-no-longer-visible-in-devtools )
2. Now focus on another tab, so the Slack chat is not visible anymore. The devtools still can be visible in that time
3. Open chrome://discards
4. Click "freeze" next to the Slack tab ( or wait 10 minutes.. )
At this stage the websocket ping / pong requests that happen every 10 seconds should have stopped. ( Websocket connection still open though )
5. Now wait 1 minute
At this stage the Slack favicon should have turned red.

Possibly related : https://chromium-review.googlesource.com/c/chromium/src/+/1038343 :
"[PageLifecycle] Restrict network activities during onfreeze callback Only fetch(request, {keepalive: true}) is allowed as it is guaranteed to be delivered even if the renderer gets discarded."

WebWorkers seem unaffected, as I'm still getting notifications even after the tabs disconnected. Although I saw Issue 776416 where Page-Lifecycle would also affect WebWorkers in the future.


Basically the issue for me is that I do want these tabs to never freeze and always stay connected.

Re 4&5: Which version of Chrome are you experiencing this in? And are you experiencing this on desktop or on mobile?

Chrome Canary on Mac - Version 69.0.3466.0 (Official Build) canary (64-bit)

Happens on the latest versions since about 3-4 weeks for me. Tabs keep freezing, even if pinned.

Hm, interesting. The document.onfreeze should be called only on mobile. Could you grab a trace and share with us as described there: https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs

The interesting categories are toplevel, renderer.scheduler and disabled-by-default-renderer.scheduler.

OK, I recorded a 11 minute session where this happened :
https://www.dropbox.com/s/ke3u9ur3ay2jng0/trace_onfreeze_desktop_chrome_canary.json.gz?dl=1

Ah, this is sounds like the desktop freezing experiment. It's Canary-only and we shouldn't have any immediate plans to ship it.

+fdoray@.

Is there any way to opt-out? This is super-frustrating :|

I've tried with many flags, but no luck.

I think ( hope ) this is resolved now since the latest update with Version 69.0.3481.0 (Official Build) canary (64-bit)

The proactive tab freezing and discarding experiment is disabled by default. This issue will be fixed before the experiment is re-enabled.

For the Slack issue, see  https://crbug.com/860555 .

For the Hangouts issue, can you confirm if this was observed during a video chat with webcam, during a screenshare, or both?

Re hangouts: both.

Can you provide your version number and variations (available at chrome://version/)?

From Chrome 69.0.3497.4+, you should see "Tab is currently capturing the camera and/or microphone" or "Tab is currently capturing a window or screen" when you hover the symbol in the Can Discard or Can Freeze column of the Hangouts tab in chrome://discards while in a VC, and no freeze or discard should happen.

I believe that this issue has been fixed. Please re-open if it happens again. Provide the version number and a screenshot of chrome://discards.