Looks like we need to tweak the design proposed in #c7 above because renderer-side activation states fails in certain OOPIF cases. For example, the following browser_tests fail because consecutive postMessages in renderer(s) can go ahead of the IPCs sent between renderers.
ChromeSitePerProcessTest.PostMessageSendsSecondPostMessageWithUserGesture
ChromeSitePerProcessTest.TwoPostMessagesToDifferentSitesWithSameUserGesture
Here is Daniel's proposal to move old user activation code (v1) to browser side to fix similar problems:
https://docs.google.com/document/d/1SuuaGe-d64FEz0ZMGu5FAEEJtMSvL77YGz4V9J1NUwo/edit?ts=5aa6d38c#heading=h.7nki9mck5t64
We met f2f during Blinkon to find a middle ground since fixing the old code looks like a wasted effort (we expect a lot of test regressions similar to ones we are facing for v2).
Now it seems that we can incrementally fix UAv2 OOPIF failures as follows (affecting only a portion of v1):
1. Move all activation consumption code to the browser side. This would affect both v1 and v2 but only a handful of APIs rely on consumption so handling regressions should be relatively easy.
2. Gradually move activation notification for only UAv2 to the browser side. This would affect many APIs, and Issue 826293 could be a blocker. I believe the end result should be simpler than what we have today because most of the notification code today are there because of token-passing behavior of v1 (which should be gone in v2).
3. Once v1 and v2 notifications are completely isolated (in renderer and browser respectively), it should be easy to get rid of v1.
Last week we were able to fix most of the site-isolation browser test failures we had (and also pass an old failure) except one: TwoPostMessagesToDifferentSitesWithSameUserGesture. It turned out that our design (crrev.com/c//967260) can't fix this important case unless we move activation consumption to browser-side.
Last Friday, dcheng@, alexmos@ and I met and agreed to proceed with the plan in #c15 above.
We are done with most of Step 1 as in #c15 above. Hence removing blocked Issue 789591 as we are going ahead with a field trial.
We plan to finish Step 1 and start Step 2 this quarter.
It seems Step 1 in #c15 is more involved, not all callers can move the consumption to the browser process.
E.g. we recently added a new consumption call in FrameLoader::StartNavigation (crrev.com/c/1232200) where a blocking call seem unacceptable.
Given that the basic OOPIF support for UAv2 is done already, we will close this bug and track the remaining steps (Step2, Step 3) in #c15 through a new bug.
Comment 1 by mustaq@chromium.org
, Nov 1 2017