Interesting. I can see the issue with moderate binding we recently introduced in  issue 485867 . Before that, the background tab has lower priority than the initial one. Now if a tab is backgrounded, but the browser hasn't been backgrounded yet, that tab has the same priority as the new process.

On Android, we can adjust the process priority. But we probably don't want to start with high before it is committed as it may get the current renderer process killed. 

See  crbug.com/537671 . Let's look into removing the determinedVisibility() hack and match the desktop initial state (visible?).

I think we mainly have to look at the 'open in new tab' use case again and make sure we don't regress.

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

commit 08d3d94b234905611bbba4cbcbba92477aa2987f
Author: gab <gab@chromium.org>
Date: Thu Apr 07 01:05:51 2016

Disable UpdateProcessPriority() on startup by default.

Ref https://cbug.com/560446#c22 for experiment results.

BUG=579116,  560446 ,  601184 

Note: PS1 copied from https://codereview.chromium.org/1763353002/ per incorrect base URL there.

Review URL: https://codereview.chromium.org/1769123002

Cr-Commit-Position: refs/heads/master@{#385608}

[modify] https://crrev.com/08d3d94b234905611bbba4cbcbba92477aa2987f/chrome/browser/renderer_host/render_process_host_chrome_browsertest.cc
[modify] https://crrev.com/08d3d94b234905611bbba4cbcbba92477aa2987f/content/browser/renderer_host/render_process_host_impl.cc
[modify] https://crrev.com/08d3d94b234905611bbba4cbcbba92477aa2987f/content/public/common/content_features.cc
[modify] https://crrev.com/08d3d94b234905611bbba4cbcbba92477aa2987f/content/public/common/content_features.h

Bug triage: gab@, you seems to be working on this, let me assign this bug to you.

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue has been moved once and is lower than Pri-1. Removing the milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I'm looking into removing "determinedVisibility", ie the bug this got merged into. I see desktop explicitly chose to put a new process in the foreground, even if the tab is in the background. But android got left behind.

Can anyone dig up this thread and forward it to me:

> On Android however this is not possible as the bindings explicitly have to be set on process creation FWIU (ref. email discussion in Sep2015 between sebsg/gab/ncarter/jaekyun/sievers/klobag)...

Arguably, desktop is actually being intentionally incorrect here, which makes it super hard to reason about correctness. Also I can think of reasons android might not want to behave like desktop. But I'd rather read that thread first :p

imo this comment from nick is the more correct way to fix the desktop issue:
https://bugs.chromium.org/p/chromium/issues/detail?id=560446#c26

I don't see any replies on that bug, so not sure if that's already been discussed to be a bad solution or something?

Re. "thread between sebsg/gab/ncarter/jaekyun/sievers/klobag": looks like retention policy ate it :(... don't know that it was bound to a google group discussion (that was a mistake...).

Responding to other comments on dupe bug.

PS: a "mistake" you can blame me for... I've since learned to tie every meaningful discussion to a group for retention...