GitLab

The separate observer has a couple of advantages.

Firstly, it allows waiting and access to occur after the
content::Portal (and its interceptor) may have been destroyed.
Instead, it's valid as long as the Portal is valid when the
observer is created.

Secondly, it allows examination of the activate result.

Since there are existing tests which rely on the ability to
observe activation immediately after a portal is created or
adopted (ideally we would more explicitly sequence these events
in the test, but this is not always possible), the created
observer is augmented with the ability to run a callback
immediately (rather than after the run loop quits, which is
subtle due to other work in the same task and nested run loops).
This is used to create a PortalActivatedObserver immediately
when the Portal is created, before the browser UI thread can
process any task which might either activate or destroy the Portal.

This mostly makes PortalInterceptorForTesting an implementation
detail of the more specific observers.

Change-Id: I6ee3bd8e847235654cc4a063659818e2e970c2b1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1900258
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: Lucas Gadani <lfg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#716374}