Tested the issue on Mac OS 10.12.6 sierra (Retina & Non-Retina) using chrome latest dev M62 #62.0.3202.9  & M63 #63.0.3207.0 and issue is not reproduced.

On command-click a link on a page , the link loads in the background tab successfully.

Attached screencast for reference.

@MTV Team-- Could someone look into this , as inhouse team doesn't have the mac os 10.11.6 configuration.

Thanks!

Deleted: 762775.mp4 2.2 MB

	762775.mp4 2.2 MB View Download

:(

This is definitely happening on my Mac at home. I'll look further.

I restarted Chrome and now it's working just fine. Weird.

And it's back...

Something is happening here. Searching for a repro.

Do you need to leave Chrome running for an hour before it reproduces?

I'm seeing this again, on my personal MacBook Pro. 63.0.3213.3 dev channel, macOS 10.11.6 (15G1611).

I see this on both my personal and work profiles.

Personal profile:
c134752e-b8b72c88
16e0dd70-3f4a17df
61fba06-ca7d8d80
da89714-4ad60575
c68ab9a3-3f4a17df
1e528f0f-3b7f37f3
ca05d627-3f4a17df
7c1bc906-e919d5bc
47e5d3db-3d47f4f4
1c752ce9-ca7d8d80
776de70c-e0278d3d
5ca89f9-f23d1dea
19c1fdaf-3d47f4f4
ed7ba060-f23d1dea
9e201a2b-94087939
44c96c7b-7968b21c
68812885-4d2fac87
332a4d9b-5e11c051
684d1cdf-51126808
b684f56f-3f4a17df
9773d3bd-7c7ea110
9e5c75f1-44ac4432
e79c5ffa-f23d1dea
f79cb77b-3d47f4f4
23a898eb-f655d281
ab7c3406-3f4a17df
4ea303a6-f23d1dea
12be2281-3f4a17df
d92562a9-4e0e29ca
1aecb842-3f4a17df
4932440-22650c6d
ad6d27cc-c6d02f41
23496387-1b127e42
796ee5fe-cf4f6ead
b2f0086-d3486be4
ef25c1eb-f23d1dea
344833e9-473e8c2e
3f273a97-25a103a9
4bc337ce-402fd06c
9a2f4e5b-ca7d8d80
3ac60855-486e2a9c
f296190c-fd6d2f5a
4442aae2-6e3b1976
ed1d377-e1cc0f14
75f0f0a0-a5822863
e2b18481-bca011b3
e7e71889-e1cc0f14
f5fff3a2-3f4a17df
bbb8f811-f23d1dea
94e68624-3f4a17df
8db050d4-7035c395
11d91db8-3f4a17df
828a5926-8f2c913
da4aaa01-f23d1dea

Work:
c134752e-b8b72c88
16e0dd70-3f4a17df
61fba06-ca7d8d80
da89714-4ad60575
c68ab9a3-3f4a17df
1e528f0f-3b7f37f3
ca05d627-3f4a17df
7c1bc906-e919d5bc
47e5d3db-3d47f4f4
1c752ce9-ca7d8d80
776de70c-e0278d3d
5ca89f9-f23d1dea
19c1fdaf-3d47f4f4
ed7ba060-f23d1dea
9e201a2b-94087939
44c96c7b-7968b21c
68812885-4d2fac87
332a4d9b-5e11c051
684d1cdf-51126808
b684f56f-3f4a17df
9773d3bd-7c7ea110
9e5c75f1-44ac4432
e79c5ffa-f23d1dea
f79cb77b-3d47f4f4
23a898eb-f655d281
ab7c3406-3f4a17df
4ea303a6-f23d1dea
12be2281-3f4a17df
d92562a9-4e0e29ca
1aecb842-3f4a17df
4932440-22650c6d
ad6d27cc-c6d02f41
23496387-1b127e42
796ee5fe-cf4f6ead
b2f0086-d3486be4
ef25c1eb-f23d1dea
344833e9-473e8c2e
3f273a97-25a103a9
4bc337ce-402fd06c
9a2f4e5b-ca7d8d80
3ac60855-486e2a9c
f296190c-fd6d2f5a
4442aae2-6e3b1976
ed1d377-e1cc0f14
75f0f0a0-a5822863
e2b18481-bca011b3
e7e71889-e1cc0f14
f5fff3a2-3f4a17df
bbb8f811-f23d1dea
94e68624-3f4a17df
8db050d4-7035c395
11d91db8-3f4a17df
828a5926-8f2c913
da4aaa01-f23d1dea

From the sound of it, this bug is in the loading stack above //net, so removing "Internals>Network".  Feel free to re-add if you have some reason to think it's actually under //net.

Both your personal and work profiles are in ResourceLoadScheduler-Enabled_bg_limit_3 Finch study group, which aggressively throttles requests from background tab.

toyoshim@, could you handle this?

I'm running a field study to limit the number of sub-resource loading in Blink.

In your group, Enabled_bg_limit_3, the number of outstanding requests per frame in background tabs are limited to 3. But, synchronous requests and requests from Fetch API escape from the limit.

Can you provide more detailed information about what pages you are loading? If the page contains 3+ hanging requests, the page loading would hang up.

15% of Canary/Dev/Beta users are assigned to the Enabled_bg_limit_3 group, and other two 15% groups are done to the Enabled_bg_limit_5 or Enabled_bg_limit_16 group.

When I first start Chrome, command-clicking links works as expected.

After about an hour, command-clicking *any* link yields a background tab that just spins counter-clockwise forever until you switch to it.

Any link, any page. It doesn't seem to be about subresources; it doesn't bother loading the main page content.

Hum..., ResourceLoadScheduler does not hook loading requests for the main page content. So, there may be another reason.

Could you try setting the field study flag to Disabled explicitly to confirm if the problem still can happen even with the Disabled setting?

chrome://flags/#enable-resource-load-scheduler is the flag.

I will also try it.

Removing 'TE-NeedsTriageFromMTV', since it's been actively investigated.

Until now, I haven't succeeded to reproduce the issue yet, on Linux.
This may actually be a mac specific issue.

FYI, my tried steps to reproduce the issue.

1. open chrome, and search something from the omnibox.
2. see Google search results in the first tab, and wait for one day.
3. click search results with the center button to open the link in a new tab.
4. see what happens without changing the active tab.
5. page title appears in the background tab with a spinner, and eventually, spinner stops.

I tried to reproduce this issue on mac with local build of ToT.
But, as far as I do the step of comment 17, I still can not reproduce the problem.

Here is a command line arguments to force joining the Enabled_bg_limit_3 group
open out/Release/Chromium.app --args --force-fieldtrials=ResourceLoadScheduler/Enabled_bg_limit_3 --force-fieldtrial-params=ResourceLoadScheduler.Enabled_bg_limit_3:bg_limit/3

Similar report in  issue 765899 , with a question around tab loading experiments.

This sounds very like my experiment for staggered background tab opening (issue 751210). Currently finch is set up to run 50%/50% on Canary/Dev (both dogfood and non-dogfood).

The idea is to delay loading background tabs. Multiple background tabs should load one after another instead of simultaneously. That is, a background tab will start to load after a previous tab finishes loading or timeout. If you switch tabs, the tab switched to will load immediately. Here is a demo video to show its intended behavior:
https://zhenw.users.x20web.corp.google.com/www/demo-with-caption.mp4

So if you open multiple background tabs, they should all load automatically after a while. Please let me know if any background tab got stuck forever. Hopefully not. :) Currently the UI shows "Loading..." or "Untitled..." for those paused background tabs. I am working on fixing the UI, too ( issue 762133 ).

And this should only happen on desktop browsers. So removing OS-Android now.

 Issue 765899  has been merged into this issue.

zhenw:

Here is the behavior I see: No tabs are loading. I command-click on a link. That sole tab spins counterclockwise forever if I don't switch to it.

I am not experiencing a delay in loading. I am experiencing nothing loading if I don't switch to it.

That's not something we want. Are you able to reproduce this? I would love to fix it if there is a bug.

You can run browser with the following flag to force the browser to enable the feature:
--enable-features=StaggeredBackgroundTabOpening,StaggeredBackgroundTabOpeningExperiment

This consistently reproduces for me on my personal MacBook, but only after Chrome has been running for a few hours.

I have some potential code area to double check in my mind. But not 100% sure if I can catch anything. Let me know if you see more cases. Any kind of specific reproduce action would be helpful for debugging. Thanks!

I would suggest also capturing a chrome://tracing trace with "navigation" enabled. This will be a good indicator whether any NavigationThrottle is deferring (stalling) the navigation, which can be a good clue whether to look at that part of the system or somewhere else.

Let me list up field trials those are in the variation list of the avi's report and could be potential root causes.

BrowserSideNavigation-Enabled
KeepAliveRendererForKeepaliveRequests-Enabled_20sec
LoadingWithMojo-Enabled_Launch
NetDelayableH2AndQuicRequests-Enabled3
ResourceLoadScheduler-Enabled_bg_limit_3
StaggeredBackgroundTabOpening-Experiment
SubresourceFilter-DryRunOnAllSites_LivePhishing6
ThrottleDelayable-Default

Nasko, great idea about tracing. Attached.

I started tracing, and about 10s later I command-clicked a link. I let it spin for about a half minute. I then switched to the tab and it immediately loaded. I then stopped the trace.

I'm not a trace expert, so correct me if I'm wrong, but it seems like a "BackgroundTabNavigationThrottle" held the load.

Deleted: trace_Tue_Sep_26_2017_10.57.14_PM.json.gz 20.8 KB

trace_Tue_Sep_26_2017_10.57.14_PM.json.gz 20.8 KB Download

I am now seeing this on my Windows machine at work, 63.0.3223.8 dev. In fact, it *does* say "Loading..." as the title. Perhaps it misses the closing of a tab that was loading, thinks there is always a loading tab, and never allows a background tab to load again?

Variations:
c134752e-f23d1dea
38b88822-54f732d1
16e0dd70-3f4a17df
1e528f0f-ca7d8d80
ca05d627-3f4a17df
7c1bc906-f55a7974
47e5d3db-3d47f4f4
2a33b90e-48ba8004
776de70c-e0278d3d
79616653-3f4a17df
83cae636-3f4a17df
19c1fdaf-ca7d8d80
f9884634-48391908
ed7ba060-3f4a17df
9e201a2b-65bced95
591576c8-ace4e138
44c96c7b-ca7d8d80
68812885-4d2fac87
e4e9ce8f-3d47f4f4
8fa604e0-f23d1dea
9e5c75f1-3c439a48
8ef0eb0f-7e93edd
350fabdd-1cf80f06
e79c5ffa-65bced95
f79cb77b-3f4a17df
ab7c3406-3f4a17df
8a4c8a2a-f23d1dea
4ea303a6-ecbb250e
12be2281-f23d1dea
d92562a9-8aa4a421
447469ba-f23d1dea
7aa46da5-4ae2ba07
1aecb842-3f4a17df
1bced4a3-7f6272b7
4932440-f23d1dea
ad6d27cc-3e870323
f3ea30a0-84708353
23496387-1b127e42
8f86a245-c306c9a2
b2f0086-870290a7
4dd0cc0f-377be55a
ef25c1eb-f23d1dea
4bc337ce-402fd06c
3ac60855-3ec2a267
f296190c-6960c22a
4442aae2-e1cc0f14
ed1d377-e1cc0f14
75f0f0a0-4ad60575
e2b18481-a5822863
e7e71889-e1cc0f14
f5fff3a2-3f4a17df
bbb8f811-3f4a17df
94e68624-f23d1dea
8db050d4-956ce709
11d91db8-f23d1dea
828a5926-c6c0a780
e9ce63c1-d9f366aa
81c6897f-2d9ebb2e
da4aaa01-f23d1dea

Attaching the navigation trace for my work Windows machine, though it's similar to the one I posted earlier.

Deleted: trace_Wed_Sep_27_2017_2.30.52_PM.json.gz 11.1 KB

trace_Wed_Sep_27_2017_2.30.52_PM.json.gz 11.1 KB Download

The experiment inserts WebContents into a set in WillStartRequest and removes them from a map in OnWebContentsDestroyed or OnDidStopLoading.

My guess is that OnDidStopLoading is not 100% guaranteed to be called for a given WebContents. So, we're keeping the vestigial contents in the set preventing further loads. However, I'm not confident enough with the API to know for sure.

Actually, the navigation throttle and its associated navigation handle are removed in OnDidFinishNavigation instead of OnDidStopLoading. Does that make a difference?

And then when receiving OnDidStopLoading, it will load the next tab if there is any pending one. There is also a timer to load a next tab after 10 sec if the previous tab has not finished.

Then perhaps my theory was wrong. In any case, the loading tab will spin at least several minutes with no noticeable change. The only evidence I have are the two traces which point to the BackgroundTabNavigationThrottle holding the pages from loading.

Thanks for the confirmation! I am actively looking at this problem.

csharrison@, can you confirm if it is ok to remove the throttle when receiving OnDidFinishNavigation? Would redirection or some other corner case make this fail?

zhenw, I am not sure I understand. Let me try to clarify what I was saying in #31.

There are two tabs, A and B. A starts loading, then B starts loading, but has its navigation throttled since A is ongoing (and in the set of WebContents).

B will stay deferred until tab A either reaches OnDidStopLoading or OnWebContentsDestroyed. I was thinking maybe those notifications were being lost/unsent.

Are you suggesting in #34 that you would also consider resuming B when A reaches DidFinishNavigation? It would be a major change to the loading strategy but it would be a reliable signal.

As an aside, I would recommend adding traces to help debug issues like this in the future. When a navigation is paused, you could for instance log the navigation URL that caused the pause.

You are right. B will stay deferred until tab A either reaches OnDidStopLoading or OnWebContentsDestroyed. And then B will be removed from |pending_navigation_| list and then start loading.

I was thinking maybe some |pending_navigation_| entries were mistakenly removed. So when A is done, there is nothing in the pending list. Then B cannot be started actually.

OnDidFinishNavigation will also remove the corresponding pending navigation. But now I think about it, it should not do anything because this signal happens after navigation resumes.

I haven't had more time to look through the code but I wanted to double check something with you just because it's a very subtle point when dealing with navigations: 

Does you code properly deal with the fact that there can be 2 main frame navigations (and NavigationHandles) at the same time in the same WebContents? This is possible both with and without PlzNavigate.

Oh, that is new to me. I will need to rethink the whole process with that assumption.

When will that happen (2 main frame nav in the same WebContents)?

Please take a look at the test ChromeNavigationBrowserTest.SlowCrossProcessNavigationWithPushState, which shows how this can happen with the pushState API. I am not sure about other cases other than push/replaceState, but maybe that was what happened.

Re comment 38, if you have to rethink how you're doing this, perhaps turn off the field trial in the meanwhile?

Yay, I have sent out a CL to disable it.

I looked at the 2 main frame navigation in one WebContents case. I don't think it applies to my experiment. That situation only happens with some existing page tries to navigate away. For all background tabs in my case, I only consider if it is the initial navigation. For each WebContents, there should be just one and only one initial navigation.

I re-read the whole thread and summarize the observations so far:
1. This happens after browser is running for a while.
2. When no existing tab is loading, command-clicking *any* link yields a background tab that just spins counter-clockwise forever (gray spinner instead of blue).
3. The pending background tab can load when you switch to it.

Here are the implications:
1. If there was no existing tab loading, the first background tab should load right away. This implies that TabManager still thinks there are some tab is loading and it decides to pause the new background tab. 
2. Pending navigations are still kept in the |pending_navigations_| list, so not mistakenly removed, because switching to a tab will load.
3. |force_load_timer_| may not work properly. Every time TabManager pause a tab, it will start the timer (10 sec timeout). When timeout, it will force load a tab.

All the above implications have one assumption, i.e., the system is not under memory pressure. With such assumption, I double checked the code and it seems to me those implications do not hold.

When the system is under memory pressure, TabManager will not automatically load the next background tab, even if the timer fires. That tab will only load if the user switches to it. Currently MemoryPressureMonitor works on Win/Mac/ChromeOS. So far, the reported cases are on Mac and Win, possibly due to this.

avi@, could it be due to the system is under memory pressure? The browser running for a few hours may make the system under memory pressure, I guess?

By the way, my disable CL is ready to land. I haven't clicked the submit button, because I want to make sure whether it is a bug or intended behavior. I am running a ToT build with the flag enabled myself right now. So far, I haven't been able to reproduce. I will keep trying.

I am going to add some trace events to help debug in the future by the way. Thanks for the suggestion csharrison@!

I'm not certain I was seeing symptoms only after the browser was running for a while.

I think being in a situation where we never load any background tabs (because we think we're under memory pressure) is bad.  At the very least, we'd want to have UI that indicates that the tab is intentionally not being loaded due to perceived memory pressure.  Better would probably be to load the new tabs anyway, while discarding old ones more aggressively?

"avi@, could it be due to the system is under memory pressure? The browser running for a few hours may make the system under memory pressure, I guess?"

No. Absolutely not. I have seen this multiple times on multiple machines. It cannot be that they are all under memory pressure. In fact, this is happening right now on my personal MacBook. 2GB free memory, screenshot attached.

I don't understand how "it takes a while to start happening" would necessarily imply memory usage. Perhaps some code doesn't properly handle some obscure case, and accidentally I run into that obscure case after fooling around on the web for a while. All I meant by that is that I don't have a clean repro.

Deleted: Screen Shot 2017-09-28 at 11.29.25 PM.png 129 KB

	Screen Shot 2017-09-28 at 11.29.25 PM.png 129 KB View Download

Yeah, I'm on a home system with 16 GB of memory, and it's unlikely I was under memory pressure (I basically never am unless building Chrome).

The policy here is to stop loading background tabs once reaching *moderate* memory pressure (not have to reach critical pressure). So it is possible that you still have some memory left in the system when the browser decides to stop loading more background tabs. "it takes a while to start happening" does not necessarily imply memory usage. It is just one possibility if the user opens many tabs.

Given the randomness of the situation. Both memory pressure and corner case bug are possible. Since we lack the trace events to help debug, and we cannot reproduce reliably, it is hard to proceed. So here is what I am going to do:
1. Turn off finch on Dev, but keep finch on Canary. I think this is a good tradeoff while we are unclear about the root cause.
2. Add trace events for easier debugging, which should help find the root cause.
3. Go through the code again myself for sanity checks.
4. After trace events are added and double checking all corner cases, I will re-enable the finch on Dev again. Then we should be able to identify the problem if it happens again.

Any other suggestions are welcome.

Re #44, I filed a bug 770042 about giving user indication on the browser intentionally not loading background tabs. That probably needs to go through the UI team and we can discuss that from there. We currently have some other UI issue that I am going to fix (fixing the tab strip UI  issue 762133 )

Whether or not we should be aggressive about stopping loading background tabs is out of the discussion scope here. It is part of the TooManyTabs project and I think the overall decision is that we want to be much more aggressive than before in general. To find a balance, better UI and options are necessary. I filed a bug to add an option for power users to disable this feature if the user wants to load background tabs immediately anyway ( issue 770013 ).

Your "next steps" sound good to me.

The policy "to stop loading background tabs once reaching *moderate* memory pressure (not have to reach critical pressure)" baffles me.

My personal MacBook is not an underpowered machine. The idea that having two windows and fifteen tabs open is too much for it to handle surprises me to the point where, if that is indeed the reason, I would get incredibly vocal that this is the wrong approach.

You definitely need to add to tracing if the throttling is due to memory pressure. That would very quickly resolve this question.

Another data point.

The Chrome on my work PC has gotten into the "background tabs don't load" state. I opened a new window with the "about Chrome" tab and closed all other windows. In the new window I middle-clicked a link and it is refusing to load while in the background, and has been spinning for about three minutes now.

If this is indeed about memory, then your memory indications are completely broken, because "moderate memory pressure" signals should not be kicking in with one window and two tabs.

This is why we explicitly need logging about our memory situation. Either it _isn't_ about memory and the background tab throttling code isn't behaving correctly, or it _is_ about memory and the memory pressure code is *very* much not behaving correctly.

Deleted: Screen Shot 2017-09-29 at 10.28.36 AM.png 116 KB

	Screen Shot 2017-09-29 at 10.28.36 AM.png 116 KB View Download

 Issue 770441  has been merged into this issue.

I just ran into this on Canary.

> The policy here is to stop loading background tabs once reaching *moderate* memory pressure (not have to reach critical pressure).

I was under the impression that we didn't have any reliable memory pressure signals on macOS. What are you using?

+ sebmarchand, who will be building reliable memory pressure signals

If we're using the OS memory pressure signal, then two thoughts:
  1) We shouldn't use it. See Issue 713463.
  2) My machine is under "normal" memory pressure, but I"m experiencing this bug.

Thanks for the pointer Erik!

We are actually using MemoryPressureMonitor, i.e., using OS memory pressure signal... Looks like we should not use it until it is fixed. Will put it on the top of my TODO list.

Do you know if the memory pressure signal is good on Win and ChromeOs?

A few thoughts:
1. Until proactive tab discarding ships, we won't have a good sense of expected user behavior around unloaded tabs.
2. Background tab opening seems distinctly different from session restore. With background tab opening, I would expect users would prefer that we proactively unload an existing tab in order to load the new one. With session restore, we can prevent getting in the situation of having too many tabs in the first place by only loading N.
3. OS memory pressure signals don't seem to match what we want for session restore or proactive tab discarding and session restore will probably want to use whatever memory trigger we come up with for proactive tab discarding (or vice versa).

So, my conclusions from that are:
1. Background tab loading shouldn't do anything special with memory at all. Eventually proactive tab discarding will automatically make it so that background tab loading unloads existing tabs if we're exceeding some memory threshold, but background tab loading doesn't need to specially handle it. In fact, the existing tab discarding effectively does this already, it just does it a bit too late.
2. Once session restore is using the same code as background tab loading, it could be a good guinea pig for figuring out a good memory signal (likely a function of total system memory) that proactive tab discarding uses once it's ready, i.e. don't restore more tabs once we hit the limit until the user focuses them. A key point is that session restore and background tab loading would continue to have slightly different logic even though they'd be built on the same infrastructure.

Please speak up if anything I said is wrong of course.

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

commit 1ad4b66f825959ff6972cd54fde27834b31f60b5
Author: Zhen Wang <zhenw@chromium.org>
Date: Wed Oct 11 21:26:43 2017

Add trace events for staggered background tab opening

This CL adds trace events for staggered background tab opening feature for
easier debugging.

Bug:  762775 , 730098 ,751210
Change-Id: Iccedbd8e5b6be8eb1ad9ca6a9f979124c741c91c
Reviewed-on: https://chromium-review.googlesource.com/706676
Reviewed-by: Chris Hamilton <chrisha@chromium.org>
Reviewed-by: oysteine <oysteine@chromium.org>
Commit-Queue: Zhen Wang <zhenw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#508121}
[modify] https://crrev.com/1ad4b66f825959ff6972cd54fde27834b31f60b5/chrome/browser/resource_coordinator/tab_manager.cc
[modify] https://crrev.com/1ad4b66f825959ff6972cd54fde27834b31f60b5/chrome/browser/resource_coordinator/tab_manager.h

Today, I am landing the CL to re-enable finch for this feature on M63 (Canary and Dev). The difference from M62 is that trace events have been added. The feature code is not really changed. So I am expecting this bug will show up again on Dev. If you see this bug again, kindly grab a trace with "navigation" category. And then you should be able to see trace events for TabManager. That will help us to see if it is due to bad memory signal. For more details on the trace events, see the CL in comment 57.

FYI, M63 will be pushed to desktop starting from Wed (10/18).

I think ojan's comments in #56 are quite pertinent. I also think pkasting's comment in #44 is insightful in that we should consider loading newly requested tabs and discarding an existing tab.

The easiest fix from my point of view would be to disable to the memory pressure trigger for now, as it appears to be hopelessly broken on all platforms.

I want to take the chance to confirm that it is actually due to memory signal, so that we do not miss any other potential bug. Once we are certain that it is due to the memory signal, I can disable it until the signal is fixed.

Re #60, SGTM

OK, this is happening again on my personal MacBook. I did a trace and it's attached.

I'm not sure what I'm looking at to see if it's a memory pressure issue.

Deleted: trace_Fri_Oct_20_2017_1.29.58_AM.json.gz 20.4 KB

trace_Fri_Oct_20_2017_1.29.58_AM.json.gz 20.4 KB Download

erikchen suggested that I might know the memory pressure status from the color of the graph in Activity Monitor. Here's the screenshot but I don't know how to read the color there either.

Deleted: Screen Shot 2017-10-20 at 1.36.43 AM.png 56.3 KB

	Screen Shot 2017-10-20 at 1.36.43 AM.png 56.3 KB View Download

I just downloaded your trace and verified that it is due to memory pressure. See attached file.

background_tab_loading_mode is 1, which means paused:
https://cs.chromium.org/chromium/src/chrome/browser/resource_coordinator/tab_manager.h?l=190

And the loading mode becomes paused when there is memory pressure signal.

I am thinking about waiting for another day or two before turning off the experiment on Dev, so that we can have more cases to make sure it is solely due to memory pressure.

Deleted: Screen Shot 2017-10-19 at 10.46.47 PM.png 65.1 KB

	Screen Shot 2017-10-19 at 10.46.47 PM.png 65.1 KB View Download

Ah, I didn't know that was what "1" meant.

This is good to know that this is confirmed; I'm on board with your plan to wait a bit for more confirmation.

Memory pressure colors: Green - no pressure. Yellow - moderate. Red-critical. Or you can just look at the stats themselves - 2.4GB compressed, 1.8GB swapped is not very high for a machine with 8GB physical RAM.

I just started getting this on my work machine (32G RAM) after a rogue app ate up all the memory and I killed it. It seems like at least one of the many ways that memory signals are broken on the Mac is that once they're triggered they stay triggered forever.

I have a CL under review to remove the dependency on memory pressure signal. Will disable finch on Dev shortly. Please let me know if you see any case if it is not due to memory pressure signal causing it goes to paused mode. Thanks!

MEMORY_PRESSURE_LEVEL_NONE is never actively generated by MemoryPressureListener; as per the comment in the header (see https://cs.chromium.org/chromium/src/base/memory/memory_pressure_listener.h?l=51), that value is only provided for call-sites which need to maintain a notion of the current memory pressure state. Only MODERATE and CRITICAL levels will actually trigger notifications.

I think this means that the switch added on OnMemoryPressure() by https://chromium-review.googlesource.com/c/chromium/src/+/585212 will never re-set the tab-loading state to Staggered, so once a system encounters memory pressure and enters the Paused state, it will never recover?

Ah, I see. That is tricky. Is there a way for us to know when the memory pressure level goes back to normal?

Re #70: Not with the MemoryPressureListener API, no; it's essentially designed to reflect the signals that Android and Mac OS provide, which fire when under pressure, with no "back to normal" indicator.

sebmarchand@ is working on a SwapThrashingMonitor that will initially provide a method to let the caller query the current level of swap thrashing (which we think is likely a more meaningful measure of memory "pressure"). That is still a work-in-progress, though, and the current interface doesn't provide event notifications, only the ability to query the "current" level.

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

commit 9e9145444160678e051bfe1e4bed1ad1647405c0
Author: Zhen Wang <zhenw@chromium.org>
Date: Tue Oct 31 17:37:31 2017

Do not pause/resume background tab opening based on memory pressure signal

Memory signal is currently unreliable. We should not pause or resume
background tab opening based on the memory pressure signal.

Bug:  762775 , 730098 
Change-Id: Ic976493bb7af94c451d54e8c8f655dbdd6b2421e
Reviewed-on: https://chromium-review.googlesource.com/736869
Reviewed-by: Chris Hamilton <chrisha@chromium.org>
Commit-Queue: Zhen Wang <zhenw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#512863}
[modify] https://crrev.com/9e9145444160678e051bfe1e4bed1ad1647405c0/chrome/browser/resource_coordinator/tab_manager.cc
[modify] https://crrev.com/9e9145444160678e051bfe1e4bed1ad1647405c0/chrome/browser/resource_coordinator/tab_manager_unittest.cc