Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
This commit adds syncing support to the `StorageSyncArea` class, via
the Golden Gate library.
It also changes the `BridgedEngine` trait: `initialize` and `finalize`
haven't been useful in practice, since that's managed by the storage
service, and the `LazyStore` takes care of setting up the storage
connection on first use. But, what we do need is a way to signal a
sync is starting, so that the engine can set up temp tables. That's
handled by the new `sync_started`.
Finally, this commit changes `BridgedEngine::set_uploaded` to take a
`sync15_traits::Guid` instead of a `String`.
Differential Revision: https://phabricator.services.mozilla.com/D73415
We need to disconnect the stream filter on redirect and allow the extension
to create a new filter. However, we also must always retain the channel
provided to us in onStartRequest, otherwise onStop fails. The request passed
to onStartRequest is always the right channel.
Differential Revision: https://phabricator.services.mozilla.com/D53187
This commit wires up `StorageSyncArea::teardown()` to call the new
`webext_storage::Store::close()` method.
It also changes `teardown` to drop the `LazyStore`, and thus close its
database connection, on the main thread if dispatching to the task
queue fails. Dispatch should only fail at shutdown, and putting the
owned reference back only adds indirection, since the `StorageSyncArea`
will still drop its `LazyStore` later in shutdown.
Finally, it includes an xpcshell test fix for
https://github.com/mozilla/application-services/pull/3050.
Differential Revision: https://phabricator.services.mozilla.com/D72992
ExtensionPolicyService::CheckContentScripts does retrieve mContentScripts a WebExtensionPolicy instance
and it may call the ExtensionProcessScript methods PreloadContentScript or LoadContentScript while iterating
over it mContentScript.
Both PreloadContentScript and LoadContentScript are going to run some privileged JS code, and LoadContentScript
will load an extension content script. There is a chance that some of the JS code executed could call
WebExtensionPolicy::UnregisterContentScript (or RegisterContentScript) and mutate the mContentScripts array
that EPS::CheckContentScripts is already iterating over, and when that happens it is possible that once the
execution goes back to the ongoing CheckContentScripts iteration, the iterator is invalidated and
the InvalidArrayIndex_CRASH triggered.
Differential Revision: https://phabricator.services.mozilla.com/D69336
The `webext_storage_bridge` crate introduced in this commit bridges the
`mozIExtensionStorageArea` XPCOM interface to the `webext_storage` Rust
component from Application Services.
This commit factors out the following parts from bug 1623245, so that
we can land them piecemeal:
* The `mozIExtensionStorageArea` interfaces, which implement all the
methods needed to support the `storage.sync` API.
* A Rust implementation of the above, in `StorageSyncArea`.
* A `StorageTask` type, for dispatching storage operations to a
background task queue.
* A `LazyStore`, which wraps the Rust component's `Store` and lazily
initializes it on the background queue the first time it's used.
* A `StorageSyncService`, which is our singleton. It holds on to a
configured `StorageSyncArea`, and hands out references to it via
`getInterface`. Eventually, we'll extend this to support syncing,
too.
Differential Revision: https://phabricator.services.mozilla.com/D71897
The `webext_storage_bridge` crate introduced in this commit bridges the
`mozIExtensionStorageArea` XPCOM interface to the `webext_storage` Rust
component from Application Services.
This commit factors out the following parts from bug 1623245, so that
we can land them piecemeal:
* The `mozIExtensionStorageArea` interfaces, which implement all the
methods needed to support the `storage.sync` API.
* A Rust implementation of the above, in `StorageSyncArea`.
* A `StorageTask` type, for dispatching storage operations to a
background task queue.
* A `LazyStore`, which wraps the Rust component's `Store` and lazily
initializes it on the background queue the first time it's used.
* A `StorageSyncService`, which is our singleton. It holds on to a
configured `StorageSyncArea`, and hands out references to it via
`getInterface`. Eventually, we'll extend this to support syncing,
too.
Differential Revision: https://phabricator.services.mozilla.com/D71897
We must wait for the iframe created by extension1 to be fully loaded before we can attempt to send a message to it.
So we send a message when it is ready, and suspend the execution until this message is received.
Differential Revision: https://phabricator.services.mozilla.com/D70008
We must wait for the iframe created by extension1 to be fully loaded before we can attempt to send a message to it.
So we send a message when it is ready, and suspend the execution until this message is received.
Differential Revision: https://phabricator.services.mozilla.com/D70008
We must wait for the iframe created by extension1 to be fully loaded before we can attempt to send a message to it.
So we send a message when it is ready, and suspend the execution until this message is received.
Differential Revision: https://phabricator.services.mozilla.com/D70008
Persistent listeners for onMessage and onConnect are special because they
don't have parent EventManagers, so we have a lot of custom code just to keep
track of which extensions have registered them during previous runs.
In this patch, I simplify all that logic to always assume that any extension
which sends messages from content scripts has those listeners setup properly.
The only observable difference is that some poorly written extensions which
were previously broken by delayed startup will now "work" by being started
earlier if a message from a content script arrives during browser startup.
Additionally, unconfuse two different meanings of the "startup" event.
Bonus, avoid some logspam during tests.
Differential Revision: https://phabricator.services.mozilla.com/D70955
