The tabs.sendMessage and runtime.sendMessage implementations behave like
an async function: They take a callback parameter and return a promise.
So they should be handled by |callAsyncFunction|, not
|callFunctionNoReturn|.
This fixes the issue for background pages, but not for content scripts
because sendMessage is not implemented as a schema at the moment. This
will also be fixed once content script APIs are generated via Schemas.
MozReview-Commit-ID: 9p1hvOP0KSm
ExtensionContext in Extension.jsm has |extension| as an instance member,
so use it instead of passing |extension| to registerSchemaAPI's
callback.
And to make sure that this pattern also works in content processes, move
the |extension| member to BaseContext.
MozReview-Commit-ID: BgsGGCPQxJR
The problem with this test was that it was actually relying on the old
broken behaviour where the initial browser of the new window it opens
would be flipped from remote back to non-remote before loading its
contents and flipping remote again. Because it now starts remote
(and stays there instead of doing all of the extra work), the
test was more likely to fall into the trap that I described in
https://groups.google.com/forum/#!searchin/mozilla.dev.platform/1261842%7Csort:relevance/mozilla.dev.platform/gthFqog3J-M/Ypx-SNhEQgAJ
where the promiseBrowserLoaded was firing for the wrong page
load, which meant that the cookie hadn't had a chance to be
set yet.
I've converted the test to use the properly instrumented
BrowserTestUtils functions which wait for the window to be
properly ready, and it appears to pass on try with multiple
retriggers.
MozReview-Commit-ID: BtQRx7og52A
The code that checks to see whether or not we should flip the remoteness of a browser
before loading the session state into it wasn't accounting for the fact that oftentimes,
restoreImmediately isn't included, so it's undefined, which coerces to "false-y".
This caused us to very quickly destroy a TabParent, very soon after creating it. In
some cases, the IPC layer seems to not like that, and throws an OnChannelError,
which causes the TabParent ActorDestroy method to be called with an abnormal
shutdown reason, which causes the tab crash observer to fire, which bubbles the
tab crash event.
We should probably make the IPC layer more resilient to this sort of thing, but
we should also probably not flip remoteness when we really don't need to.
Now instead, when restoring a tab, we detect whether or not it's going to
be restored automatically in the near future. If it's not going to be
restored automatically, and the browser is remote, we flip its remoteness -
otherwise we leave it alone.
MozReview-Commit-ID: 5AmPHvzDZlX
Tests cannot be run in a new process, so when this test is run along
with other tests, the faulty behavior is not caught.
You can manually check whether the bug is still present by running the
test in isolation:
mach mochitest browser/components/extensions/test/browser/browser_ext_webNavigation_frameId0.js
MozReview-Commit-ID: LwumSU7zh8R
