GitLab

API bindings are created lazily on first-access. Because of this, the
active context may not be the context to which the API belongs. For
instance, a child frame may instantiate an API on its parent frame, so
that the owning context is the parent frame, but the current context (at
binding instantiation time) is the child frame.

This is problematic if we create objects during the binding
instantiation (such as the APIBindingBridge), because methods called on
these objects will be executed in the context that was active when they
were created. This means that the APIBindingBridge object, for instance,
could belong to a different context than the Chrome API for which it
was instantiated.

In addition to being strange, this can cause a crash in the case that
the child context was not fully registered with the extension system. If
the context is not registered, the C++ code cannot safely run JS code in
that context, which is necessary for API instantiation with JS custom
hooks.  Additionally, the calling context, though not fully registered,
will not be marked as invalid because it isn't scheduled for release.

Contexts can be active, but not registered with the extension system, in
the case when the registration was deferred by the ExtensionFrameHelper
because of a pending browser navigation.

This can eventually lead to a crash when we try to execute JS through
the extension JSRunner for the uninitialized context.

To fix this, force API binding construction to happen with the owning
context as the active context. In this case, the context should always
have been initialized (because otherwise we would not have set up the
hooks for API instantiation).

Bug: 819968

Change-Id: I09890560ca92743ebc855561c9119e625e61e410
Reviewed-on: https://chromium-review.googlesource.com/978791
Commit-Queue: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Istiaque Ahmed <lazyboy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#546043}