This patch adds the ability to run SingletonEventManager handlers in
different modes: sync, async, raw (no exception handling, arg cloning,
or asynchrony), or asyncWithoutClone. When you call the handler,
you're required to specify which variant you want.
Existing uses of SingletonEventManager are all converted to async calls.
Note that some of them were previously synchronous, but it didn't appear
to be necessary.
Also added a callOnClose for SingletonEventManager when the last listener
is removed.
MozReview-Commit-ID: ATHO97dWf3X
CLOSED TREE
Backed out changeset 2d42350d209a (bug 1203330)
Backed out changeset 3a12c51c3eca (bug 1203330)
Backed out changeset 31fac390e15d (bug 1203330)
This patch adds the ability to run SingletonEventManager handlers in
different modes: sync, async, raw (no exception handling, arg cloning,
or asynchrony), or asyncWithoutClone. When you call the handler,
you're required to specify which variant you want.
Existing uses of SingletonEventManager are all converted to async calls.
Note that some of them were previously synchronous, but it didn't appear
to be necessary.
Also added a callOnClose for SingletonEventManager when the last listener
is removed.
MozReview-Commit-ID: ATHO97dWf3X
- Add `envType` to BaseContext.
- Pass an explicit envType to all `registerSchemaAPI` invocations.
- The factories passed to `registerSchemaAPI` will be split up later, so
that content scripts (`content_child`) and addon pages can share
common implementations.
- The factories that implement the addon API will also be split up,
to separate code running in the main process (`addon_parent`) from
code running in a child process (`addon_child`).
- Remove the use of a hardcoded list of `namespaces` from ProxyContext.
Now `envType` is used to specify whether an API should be activated.
MozReview-Commit-ID: Jiff8HIwG92
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
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
- introducing tabTransitionData in the webNavigation internals
- listen for the "autocomplete-did-enter-text" topic notified on the observer service
- add support to from_address_bar transition qualifier and auto_bookmark/keyword/generated transition types
MozReview-Commit-ID: 7krQiJlnc1d
The base .eslintrc is essentially a merge of the root Toolkit .eslintrc and
the devtools .eslintrc, with some minor changes to match our prevalent style.
For the most enforces the coding styles that we've been using most
consistently. There are a couple of significant differences, though:
* The rule for opening brace alignment can only be applied globally, and
doesn't make exceptions for top-level functions. I chose to turn it on, and
change the brace style of existing top-level functions that violated it,
since the rule seemed worth using, and that's the direction most Toolkit JS
code has been headed anyway.
* The rule for switch/case statements requires an added indentation level for
case statements. Most of our switch statements did not use an extra level
of indentation, and I initially wrote the rule to enforce that style, until
I came across case statements that used blocks, and required the extra
indentation level for sanity.
