This fix is not related to the referenced bug but came up during review.
MozReview-Commit-ID: IjrxWzkLIq1
--HG--
extra : rebase_source : d53179af98106049bcf1a12efed74c4527ac62c1
And change `this.global.Object.create(null)` to
`Cu.createObjectIn(this.global)`. The tests pass either way, but
`Cu.createObjectIn` is more explicit.
MozReview-Commit-ID: LmL6rTru5zZ
--HG--
extra : rebase_source : 4cf7b1463bf8b6882b6fd453657eae0ff43ed64d
Split the `shouldInject` method into separate methods:
- `shouldInject` to determine whether the API (or namespace)
should be injected.
- `getImplementation` to return the actual implementation.
Introduced `SchemaAPIInterface` for documentation purposes, and
two concrete implementations `LocalAPIImplementation` and
`ProxyAPIImplementation` which provide the functionality to run a local
and remote implementation of the API for which the schema API is
generated, respectively. These classes store the necessary details for
the invocation, so the methods that were formerly in the `Context` in
Schemas.jsm no longer get the `pathObj`, `path` or `name` parameters.
And merge the `path` and `name` in the implementation of remote APIs
because there is no need for having them separate, as the callers and
callees often did redundant pre/post-processing on `data.path` because
of the way it was implemented.
MozReview-Commit-ID: isbG9i9pNP
--HG--
extra : rebase_source : 22cdc3ab3d14c6381f9f540739d6750281ae8c71
The API implementation is already available upfront when the schema API
is generated, so `pathObj` has the implementation and can be used
instead of looking up the implementation over and over again with
`findPathInObject`.
MozReview-Commit-ID: FnCIyoaxgA4
--HG--
extra : rebase_source : 440b25fcfb4a0438b1ff8680ad770930e7427de7
- This was the last non-schema-generated API in content scripts.
MozReview-Commit-ID: FaIOCHoircf
--HG--
extra : rebase_source : 7bab2249a7462a581e493f7aa937df45cb895107
- Use schema-generated runtime API for content scripts instead of
untyped API.
- Move logic that cannot be run in the main process to a new file.
Together with the previous patch that migrated the i18n API, this
concludes the fix for bug 1286712.
MozReview-Commit-ID: A3yG0x1kjwx
--HG--
extra : rebase_source : 19efe95149c423c0f9284bb70e289a282fb758c1
Use schema-generated i18n API for both content script and
addon contexts, instead of just the addon context.
MozReview-Commit-ID: AKDAFxNv6Zs
--HG--
extra : rebase_source : ea66e8bab7b4713d971614ce27e8c1d9350a0a14
- By default, schema APIs are not injected in content scripts unless
the JSON schema sets the "restrictions" attribute to `["content"]`.
- Added the "restrictions" attribute to the storage and test schemas.
Other APIs will follow in subsequent commits and make use of the
primitives introduced in this commit.
MozReview-Commit-ID: 1rNjQap0BiM
--HG--
extra : rebase_source : bf2c7fb70a38fbf13cdfd4337cb3cb6fef7e67e8
- Moved Management logic to ExtensionUtils (as SchemaAPIManager) so that
the logic can be used by addon and content processes.
- Remove the `context.extension.hasPermission(api.permission)` check in
`generateAPIs` because the only user (`registeredPrivilegedAPI`) was
removed before in bug 1295082.
- Add new category "webextension-scripts-content", intended for
registering the few scripts that must be loaded in a content process.
MozReview-Commit-ID: 81nhblV8YE6
--HG--
extra : rebase_source : d2eee0298ad5038225ea56c2e752532af0bc6fb7
- 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
--HG--
extra : rebase_source : 946a3c0009a4e3223c2d10044b3099a94c845394
Local wrappers currently look up the API object over and over again
whenever a schema API is invoked. This can be optimized by re-using
the lookup result from a `shouldInject` invocation, which is passed
as the `pathObj` parameter to the wrapper methods.
This commit adds the necessary changes and tests to allow this to
happen, but does not modify the wrapper in Extension.jsm yet.
Also, this construction allows the `ChildAPIManager` to use a local
implementation if available and fall back to a remote implementation
otherwise.
MozReview-Commit-ID: C9gm7A9Zppb
--HG--
extra : rebase_source : e2ab1e40de72fdea23acc9a68f3cf7d77e3da66f
Currently there is a tight coupling between registered APIs because they
share the same global scope, and the dependencies between the modules
that use these globals are not explicit. Consequently, it would be
possible for APIs to break when the registered APIs run in separate
processes, because then there are separate global scopes.
To mitigate this issue, this patch isolates the global namespaces of
API registrations in different environments, starting with the "chrome"
process. Content and addon processes will follow later.
A new JSM is introduced to avoid hidden dependencies between ext-*.js
and the script loader. ExtensionUtils.jsm would be a natural choice for
this shared utility method, but cannot be used because its local
`EventEmitter` implementation conflicts with the `EventEmitter` import
in ext-tabs.js.
So, this patch provides isolation of global variables declared through
`globals.XXX = ...`, but does not provide isolation for `Cu.import`-ed
logic. Ideally `Cu.import` should always use its second argument to
prevent inadvertent namespace pollution.
MozReview-Commit-ID: 1DTZaKOaeSE
--HG--
extra : rebase_source : 1376a1325fd9bf186e09e1dbe83467f3ad94516f
This only supports flac with a STREAMINFO header.
MozReview-Commit-ID: FaT9N6xJDPY
--HG--
extra : rebase_source : ba4e1f78f3a3ca9b4062edfc84445d444c323d80
This patch also makes sure that we correctly grab a weak reference to the
related window instead of just setting a "relatedBrowser" property directly on
the JS object (which shadows the XBL property getter).
MozReview-Commit-ID: 97VQyCoY1Cj
The presence of these globals interfere with the attempt to get ext-*.js
scripts to load in a content process because these globals are only
available in the main process.
MozReview-Commit-ID: 7syjAGcuUnu
--HG--
extra : rebase_source : d614424d50bbb2a5dea6c23e4dae1586b9efe4fb
The main motive for this patch is to remove the use of the GlobalManager
global (which was used to see if an extension ID is valid, which was
specifically added in order to create thebrowser_ext_lastError.js test).
To preserve test coverage I implemented a full validation of the
runtime.sendMessage method.
Now the error for a non-existent extension is identical in both the
content script and background pages. Note that this also fixes a
minor privacy leak: Previously extensions could see whether another
extension is installed by sending a message to the specified extension
and using the different responses to see whether another extension is
installed.
MozReview-Commit-ID: 82R97Ei25Xr
--HG--
extra : rebase_source : 900a65e695afd6db83d5102f515dc29d46d001f1
It is not directly related to the current bug but I added a test
for browser.extentionTypes while I was here.
MozReview-Commit-ID: 2XifKm3ZhrY
--HG--
extra : rebase_source : 855e44ebf7d595211de46a0ecbfedca107430662
Rob Wu
Ryan VanderMeulen
Sebastian Hengst
Matthew Noorenberghe
dimi
Shane Caraveo
Sebastian Kaspari
Wes Kocher
Andrea Marchesini
Christoph Kerschbaumer
Nicholas Nethercote
Jean-Yves Avenard
Blake Kaplan
Andrew Swan
Jon Coppeard
Gijs Kruitbosch